Ticket UUID: | 1414262 | |||
Title: | Errors in -command script not reported | |||
Type: | Bug | Version: | obsolete: 8.4.12 | |
Submitter: | setok | Created on: | 2006-01-25 03:43:41 | |
Subsystem: | 29. http Package | Assigned To: | aku | |
Priority: | 8 | Severity: | Important | |
Status: | Closed | Last Modified: | 2022-05-30 16:24:20 | |
Resolution: | Fixed | Closed By: | kjnash | |
Closed on: | 2022-05-30 16:24:20 | |||
Description: |
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. | |||
User Comments: |
kjnash added on 2022-05-12 01:38:23:
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]. anonymous (claiming to be whd) added on 2014-03-24 22:20:11: -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. kjnash added on 2012-10-30 10:48:53: 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. ferrieux added on 2008-04-06 05:22:36: 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. dkf added on 2006-01-26 04:32:16: Logged In: YES user_id=79902 That's in large part what I was talking about in relation to "right thing" and "compatible thing". :-) setok added on 2006-01-26 02:49:22: 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. dkf added on 2006-01-25 16:13:38: 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. :-) setok added on 2006-01-25 10:43:42: File Added - 164800: httptest.tcl |
Attachments:
- httptest.tcl [download] added by setok on 2006-01-25 10:43:42. [details]