Re: Readability of exception handling

> I showed one example of sugar.
Thank you.

> You can invent your own less C-like
> versions, such as
> 
> 	on_exception(Goal,
> 		     [ Term => { Goal },
> 		       ...
> 	             ]).

That syntax is fine too.  It's nice and clear.  I'm afraid I'm a bit out of my depth when it comes to defining new syntax.

> I rarely test on specific errors.  Occasionally on existence errors,
> as in,
> 
> 	catch(thread_signal(victim, abort),
> 	      error(existence_error(thread,_),_),
> 	      true).
> 
> I'm curious in real code where error handling must be more subtle.

I wouldn't say subtle, but more complex.  An RPC handler involves deserialising the message, parsing, executing the 
call, then depending on the type of message serialising the response and sending a response back.  Each step 
can fail or raise exceptions.  An ad-hoc implementation is easy.  Writing one that conforms to a protocol with specific requirements on
 the handling of each case is bit more involved.

Clearly there's a setup_call_cleanup around the call  My understanding is that the rest is a case of nested exception handling and getting the exception propagation right.

Cheers,
Parker
 		 	   		  
-------------- next part --------------
HTML attachment scrubbed and removed