Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#3356 Errors in -command script not reported

obsolete: 8.4.12
open
Jeffrey Hobbs
7
2006-01-25
2006-01-25
No

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.

Discussion

  • Shows how a really obvious syntax error just disappears into the void

     
    Attachments
  • 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. :-)

     
    • priority: 5 --> 7
     
  • 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

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

     
  • 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.

     
  • kjnash
    kjnash
    2012-10-30

    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.