Towards a better conceptual model of exceptions (Was: Re: The Right Approach to Exceptions)

[Artur Skawina]

On 02/21/12 09:15, H. S. Teoh wrote:
> 
> Sorry for this super-long post, but I wanted to lay my ideas out in a
> coherent fashion so that we can discuss its conceptual aspects without
> getting lost with arguing about the details. I hope this is a step in
> the right direction toward a better model of exception handling.

I haven't read all of that huge trolli^Hbrainstorming thread, as most of
it was just bikeshedding - the exception hierarchy needs to just be done;
design by committee never works. You made some good points there, and had
an interesting idea, so I'll just comment on that. 

> The try-catch mechanism is not adequate to implement all the recovery
> actions described above. As I've said before when discussing what I

Imagine that catch blocks are delegates. Now, when something throws an exception,
the catch handler is looked up, just like right now, except the stack isn't
unwound, the matching catch-delegate is called. If it returns 'X' control flow
is returned to the 'throw' scope, so that the failed operation can be retried.
If it returns 'Y' then  the search for another matching catch block continues,
that one is called and so on. If a delegate returns 'Z' the stack is unwound and 
control is passed to the code following this catch statement.

Add a bit syntactic sugar, and the result could be something like this:

void f1(C c) {
   retry:
   if (!c.whatever())
      throw(retry) new WhateverEx("Help! XYZ failed", moreDetails, errorCodesEtc);
}

void f2(C c) {
   try {
      f1(c);
   } catch (WhateverEx e) {
      if (isTransient(e)) {
         doSomethingAndPray();
         continue;
      }
      if (nothingICanDo(e))
         throw;
      if (iCanDealWithItHere(e))
         break;
   }
   /* ... */
}

Wouldn't this be enough to handle all of your cases?

If exiting the scope maps to 'break' ie means unwind-and-continue-from-here,
it's even somewhat compatible with the current scheme (you cannot jump with
goto to inside the catch blocks, but that's not a good idea anyway).

Implementation question: could this be done w/o causing heap allocation in
most functions containing catch statements?

artur