#1525 http::geturl -command doesn't propagate errors

[Marty Backe]

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.

[Donal K. Fellows]

Logged In: YES
user_id=79902

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

[Brent B. Welch]

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?

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

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

[Marty Backe]

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

[Marty Backe]

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.