Handling exceptions during callback

> Hello,
> Andreas and Eliot,
>
> i direct my question mainly to you , because you are most experienced
> in this area, but if there's others who want to share their thoughts,
> please do so.
>
> So, the question is, what to do, if an error triggered during a callback.
> My concern is, that sometimes its unsafe to do return from callback
> with invalid value.
>
> For example, if callback's caller expects a pointer to something,
> returning a default value (NULL)
> will have the same effect as simply terminating VM :)
>
> Here's my snippet of code, which i coded so far:
>
> block: aBlock
>
> self numberOfArguments = aBlock numArgs ifFalse: [
> self error: 'Invalid number of arguments' ].
>
> context := [ "here we entering a callback"
>      [
> [ | args |  args := self readArguments.
>  self leave: (aBlock valueWithArguments: args) ]
> ifCurtailed: [ self error: 'attempt to non-local return across a callback' ]
>
>    ] repeat.
> ] asContext
>
>
> when callback is activated, an interpreter should enter the context ,
> stored in callback's context ivar.
>
> The best what i invented so far, is to wrap the whole thing in repeat block.
> So, if there's error happens, there could be at least chance that user
> (like me ;) might supply the right argument to the #leave:  method,
> using debugger.
> A leave: method serves to leave callback , but also might fail, if it
> can't coerce a return value to corresponding C equivalent.
>
> Of course, there's many other variants, like
> self leave: ( [ aBlock valueWithArguments: args ] ifCurtailed: [ self
> askUserToEnterTheValue ] )
>
> i'd like to know, what you think would be the best variant.
>
>

>
> Hi Igor -
>
> I don't think there's a general approach for the problem. After quickly
> checking our internal uses of callbacks I found that usage basically looks
> like this:
>
> runCallbackProcess
>        "Run the callback process"
>        [true] whileTrue:[
>                CallbackSemaphore wait.
>                [self handleCallback] ensure:[self callbackReturn].
>        ].
>
> handleCallback
>        "Handle a callback"
>        | nArgs rcvr selector args result |
>        nArgs := self callbackGetArgCount.
>        rcvr := self callbackGetArg: 1.
>        selector := self callbackGetArg: 2.
>        args := (3 to: nArgs) collect:[:i| self callbackGetArg: i].
>        result := [rcvr callback: selector asSymbol args: args] on: Error
> do:[:ex|
>                ex return: nil.
>        ].
>        self callbackResult: result.
>
> (this is slightly simplified from original code) The point there is that if
> there's an error during the callback we simply return some predefined value
> (nil in the above) and assume that the caller can deal with that default
> return value.
>
> The alternative (that I had considered but dropped as adding too much
> complexity for to little value) was having an explicit error indication
> along the lines of:
>
>        result := [rcvr callback: selector asSymbol args: args] on: Error
> do:[:ex|
>                "Signal underlying code that we failed"
>                self callbackError: ex description.
>                ex return: nil. "still sets a default return value"
>        ].
>        self callbackResult: result.
>
> But this then assumes that the callback machinery itself has some notion of
> failure which is generally not the case.
>
> The interesting point here is that since callbacks *can* fail there must be
> some way by which one can indicate to the caller that a failure has
> occurred. However, that is exactly why I decided against having the
> callbackError: call - when you handle the callbacks you absolutely need to
> wrap them properly in an error handler and do whatever is appropriate to
> return from the callback in the case of an error. And that, of course, is
> specific to the callback in question and cannot be implemented by the
> callback machinery in general.
>
> And if your callback has no way to indicate failure, then you've got two
> choices: 1) Return some madeup value or 2) Fail and die. There are really no
> other options.
>
> So the short answer to your question is that to implement a callback
> properly you *must* specify how to respond in the case of an error. It's not
> optional and in fact, you might make that part of the interface of a
> callback, i.e., *always* require an error handler for the client to indicate
> how to respond to an error. This could be as simple as something like:
>
>        Callback action:[self doSomething] ifError:[0]. "returns zero on
> errors"
>
> or it could be more complex, but you might consider making this explicitly
> part of the callback interface.
>
> The other issue in this regard is how to debug failures. We punt on this. We
> print a callstack to indicate error and then we return the default value. So
> there's no other information than the callstack. You probably want to look
> at Newspeak to find out how to debug callbacks; there must be a few 'tricks'
> for how to ensure proper debug and return semantics. We don't have any such
> uses in Teleplace at this point.
>