[Tcl-bugs] [ tcl-Bugs-431992 ] http::geturl -command doesn't propagate errors

[<no...@so...>]

Bugs item #431992, was opened at 2001-06-10 23:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=431992&group_id=10894

Category: 28. http Package
Group: = 8.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Marty Backe (mgbacke)
Assigned to: Brent B. Welch (welch)
Summary: http::geturl -command doesn't propagate errors

Initial Comment:
http 2.3

When using the -command option with http::geturl, any errors in the procedure specified by the argument to -command are caught (via catch) and not propagated to the users program.

Although not catastrophic, catching user bugs becomes very difficult because errors are caught. If the procedure is responsible for calling http::geturl, the program will enter the event loop never to return.

The pertinent code is in http::Finish. Any user program errors are caught, and the error message is saved in variable err, however, it's never used (apparently). It's not clear to me (not having written this package) why the state(error) & state(status) variables are set when the user procedure might never be called (if the procedure specified by -command is responsible for calling http::geturl).

I could research this further and perhaps offer a solution, but it would hopefully be quicker if the person who wrote this code is still involved in its maintenance, and can offer a solution.

----------------------------------------------------------------------

>Comment By: Marty Backe (mgbacke)
Date: 2001-09-02 11:56

Message:
Logged In: YES 
user_id=150456

Thanks for the followup Don. After looking at how http::wait is implemented and revisiting what Brent wrote, 
I see the errors in my ways. I wouldn't have had my problems if I had used http::wait (instead of vwait) as 
Brent demonstrates.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-21 06:37

Message:
Logged In: NO 

[http::wait] is implemented in terms of [vwait]
so I don't understand the distinction being made
about their blocking behavior.

Also, [http::wait] isn't doing any magic regarding
[http::status] and [http::error].  They are updated
by the events set in motion by [http::geturl] whether
you wait for those events with [http::wait] or with
[vwait].

What are you [vwait]-ing on?

DGP

----------------------------------------------------------------------

Comment By: Marty Backe (mgbacke)
Date: 2001-08-20 22:10

Message:
Logged In: YES 
user_id=150456

Thanks for the suggested work-around. I see this has been 
closed (it has only been 6 days since Brent's follow-up - 
I'll try and be faster next time ;-)

I agree that http::wait does work as you suggest. In my 
application where this 'bug' came to light, I was not using 
http:wait since it blocks the application (I'm using vwait 
and doing other things while data's being collected).

This 'bug' is only an issue during program development. I 
am on the fence whether it is a bug or not. If a program 
can't make use of http::wait, then my original comments are 
still valid, yes? This just might be a case of "that's 
life". For myself, I can just modify ::http to get me 
through the debug cycle, and I can live with that.

Perhaps if nothing else, a caveat could be added to the 
documentation stating the pitfalls of not using http::wait 
(in terms of getting access to errors associated with -
command.

Thanks for the insight regarding using http::wait.

Marty

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2001-08-20 16:52

Message:
Logged In: YES 
user_id=72656

Closing this based on Brent's response (and no other follow-
up).

----------------------------------------------------------------------

Comment By: Brent B. Welch (welch)
Date: 2001-08-14 16:15

Message:
Logged In: YES 
user_id=89720

The following fragments shows how you can find out if errors
occurred.  Is this not sufficient?

package require http 2.3

proc badcommand {args} {
    error foo
}

set t [http::geturl
http://www-internal.panasas.com/index.html -command
badcommand]
http::wait $t
puts "status [http::status $t]"
puts "error [http::error $t]"


This generates:

status error
error foo {foo
    while executing
"error foo"
    (procedure "badcommand" line 2)
    invoked from within
"badcommand $token"
    ("eval" body line 1)
    invoked from within
"eval $state(-command) {$token}"} NONE

If we were really clever we could tweak the errorInfo so
it would more clearly show that it was the -command
callback.
But, the error information is preserved in this case. 
Perhaps
there is another usage case that you are thinking of?

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2001-06-11 01:30

Message:
Logged In: YES 
user_id=79902

(adjusted summary/title for greater clarity in bug-list)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=431992&group_id=10894