From: SourceForge.net <no...@so...> - 2008-04-05 22:22:30
|
Bugs item #1414262, was opened at 2006-01-25 04:43 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1414262&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 29. http Package Group: obsolete: 8.4.12 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Kristoffer Lawson (setok) Assigned to: Jeffrey Hobbs (hobbs) Summary: Errors in -command script not reported Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-04-06 00:22 Message: 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2006-01-25 22:32 Message: Logged In: YES user_id=79902 That's in large part what I was talking about in relation to "right thing" and "compatible thing". :-) ---------------------------------------------------------------------- Comment By: Kristoffer Lawson (setok) Date: 2006-01-25 20:49 Message: 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2006-01-25 10:13 Message: 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. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1414262&group_id=10894 |
From: SourceForge.net <no...@so...> - 2012-10-30 03:48:54
|
Bugs item #1414262, was opened at 2006-01-24 19:43 Message generated for change (Comment added) made by kjnash You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1414262&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 29. http Package Group: obsolete: 8.4.12 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Kristoffer Lawson (setok) Assigned to: Jeffrey Hobbs (hobbs) Summary: Errors in -command script not reported Initial Comment: 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. ---------------------------------------------------------------------- Comment By: kjnash (kjnash) Date: 2012-10-29 20:48 Message: 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. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-04-05 15:22 Message: 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2006-01-25 13:32 Message: Logged In: YES user_id=79902 That's in large part what I was talking about in relation to "right thing" and "compatible thing". :-) ---------------------------------------------------------------------- Comment By: Kristoffer Lawson (setok) Date: 2006-01-25 11:49 Message: 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2006-01-25 01:13 Message: 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. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1414262&group_id=10894 |