From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,deeb88b0e7eede4f
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Help with Exceptions!
Date: 1996/05/07
Message-ID: <dewar.831482952@schonberg>#1/1
X-Deja-AN: 153556244
references: <4mmimq$s4r@hatathli.csulb.edu> <318F353D.4531@mtm.syr.ge.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-05-07T00:00:00+00:00
List-Id: <comp.lang.ada>


Steve said

"Unfortunately perhaps, but you can't go back... the exception
terminates the current frame. The best that your exception
handler can do is recover from the error by resetting to some
default conditions, or re-raise the exception, as well as
possibly logging the error somehow."

Robert replies:

I don't think this is unfortunate at all. Replacement semantics for
exceptions are MUCH cleaner than continuation semntics. You can program
exactly what you want by narrowing the scope of the exception handler
to the desired degree of granularity -- e.g. if you want to resume at
the next statement, then put the handler round a single statement.