The Right Approach to Exceptions
H. S. Teoh
hsteoh at quickfur.ath.cx
Mon Feb 20 10:53:54 PST 2012
On Mon, Feb 20, 2012 at 06:37:07PM +0100, deadalnix wrote:
> Le 20/02/2012 06:57, H. S. Teoh a écrit :
> >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.
> I read your code with great interest ! I'm not sure about this. This
> is a lot of code to not achieve that much. OK, the stack hasn't been
> destroyed, but your delegate has its own scope and cannot do a lot.
The delegate has full access to the scope of main(), or wherever it was
registered from, which the low-level error recovery code has no access
> Isn't a retry function provided by phobos and a transeient property as
> proposed by Andrei a better alternative ?
The problem is that by the time you regain control at the catch, the
stack has already unwound to main(), so if you need to retry, you need
to call openDataFile() all over again.
In this case it's not too bad, because openDataFile() is very simple.
But imagine if this openDataFile() was nested deeply inside a few layers
of functions called from main(), then by the time you unwind the stack
to main(), all the previous work done is lost, and you have to restart
from the beginning.
Also, how does the transient property help main() know that it should
prompt the user for a different filename? What if a different exception
was caught, like NetworkDriveUnreachable? It wouldn't make sense to
prompt the user for another filename in this case.
Nearly all men can stand adversity, but if you want to test a man's
character, give him power. -- Abraham Lincoln
More information about the Digitalmars-d