Tcl Source Code

If any kind of error occurs in the script passed as a parameter to -
command, it just vanishes and is not passed to bgerror or to anything 
else. All kinds of errors are caught, including syntax errors, making 
debugging a chore at best and resulting in "why did nothing happen?" 
ponderings.

A minimal script is attached that demonstrates this.

There is no agreement on the "right thing" or the "compatible thing", so I have documented what http does in its man page. The problem confused me the first time I ran into it, but 90% of my confusion was because it was undocumented and therefore unexpected.

Documentation http(n) changed for each callback that is executed inside a catch. Longer description in section "ERRORS". See commit [277e9c6ba6d232bc].

-command is a callback; any error that occurs in it belongs to the user, and should be bubbled up to the top so that it can get caught and *fixed*.  That's standard behavior; I don't see why http is special.

Yes, this is probably the worst "gotcha" with http.  If nothing else is done about it, a prominent warning should be added to the man page.

My own workaround is that my -command script has a [catch] of its own, and if an error is detected, it calls the bgerror handler directly.

The Tk bgerror is a modal dialog that uses vwait to enter the event loop.  The reason the authors of the http package avoid raising an error might be that they did not want to use vwait.

P.S. Also reported as bug 2937318.

Logged In: YES 
user_id=496139
Originator: NO

Sorry to dig that one so late :-)
I understand that http does this because [bgerror] is not modular, and no package can hijack it from the application.
So currently it takes pains never to leave an exception reach the surface.
What about adding a [configure -error] callback for this purpose ?
This would somewhat solve setok's concern about polling.

Logged In: YES 
user_id=79902

That's in large part what I was talking about in relation to
"right thing" and "compatible thing". :-)

Logged In: YES 
user_id=137542

But this mechanism is not sufficient. The whole point of using the -command 
procedure is to provide asynchronous operation. If the callback script caused 
an error then perhaps http::error will give us that error, but we have no way 
of knowing when to look at it, without polling or by some magic mechanism 
at the beginning of the -command. We should have to do this kind of work 
just to catch script errors.

I cannot see why the -command operation cannot use the same mechanism 
as all other callbacks and find errors reported to bgerror.

Logged In: YES 
user_id=79902

Not quite. The error gets logged in the state array where
you can retrieve it with [http::error] (and the
[http::status] is error). But the error only gets logged if
the callback wasn't called to deal with an error in the
first place; if it was dealing with an error condition, the
callback failure gets dropped in a bit-bucket.

I'm not at all sure what the right thing to do is, and nor
am I sure what the compatible thing to do is. :-)

File Added - 164800: httptest.tcl