The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Sun Feb 19 21:57:46 PST 2012


On Sun, Feb 19, 2012 at 09:12:25PM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 8:52 PM, H. S. Teoh wrote:
[...]
> >Correct, so that would be a recovery strategy at the operation level,
> >say at sendHttpRequest or something like that. There is not enough
> >information available to sendHttpRequest to know whether or not the
> >caller wants the request to be retried if it fails.
> >
> >But if the higher-level code could indicate this by way of a recovery
> >policy delegate, then this retry can be done at the sendHttpRequest
> >level, instead of percolating up the call stack all the way to
> >submitHttpForm, which then has to reparse user data, convert into
> >JSON, say, and then retry the entire operation all over again.
> >
> >I'm really liking the Lisp approach.
> 
> Now we're talking. Ideas. Outside the box.
[...]

Alright. This thread has gone on for too long with lots of talk but no
down-to-earth, real code. So I decided to code up a quick-n-dirty
proof-of-concept implementation of a Lispian scheme of exception
handling. The source files are attached.

This implementation is more to demonstrate the *semantics* of such a
system, rather than a sample code of the real thing. Before anyone jumps
on me for writing very bad code. ;-)

In a real implementation, I probably wouldn't inherit Condition from
Exception, for example. A real implementation would have language-level
support for declaring recovery strategies within the function that
handles them, rather than the kludge of declaring them separately and
abusing the exception system to handle recovery actions.

Also, registered handlers would need to be cleaned up upon scope exit,
so that they don't cause crazy side-effects in unrelated code later on
in the program.

But anyway. The point of this code is to demonstrate:

(1) How an exception generated in low-level code is recovered within the
low-level code without unwinding the stack all the way back to the
top-level caller;

(2) How the top-level caller can provide a delegate that makes decisions
that only the top-level code is qualified to make, yet does so in the
context of low-level code so that recovery can proceed without unwinding
the stack any more than necessary.

I deliberately made the delegate prompt the user for a fixed filename,
even allowing the option of aborting if the user wants to give up. This
is to show how the system handles different recovery actions. This, of
course, isn't the only way to do things; you can programmatically decide
on a recovery strategy instead of prompting the user, for example.

What do y'all think?


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recover.d
Type: text/x-dsrc
Size: 1094 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120219/2d448229/attachment.d>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prog.d
Type: text/x-dsrc
Size: 1614 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120219/2d448229/attachment-0001.d>


More information about the Digitalmars-d mailing list