[Vm-dev] Re: Handling exceptions during callback

[Andreas Raab]

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.

Cheers,
   - Andreas

On 5/3/2010 4:31 PM, Igor Stasenko wrote:
> 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.
>
>