1. RE: exception handler
Derek Parnell wrote:
> Robert Craig wrote:
> >
> > I'm ready to implement the global exception handler concept.
>
> YEAH!!! (First recorded suggestion in Sep 1999 by Pete Eberlein)
Actually, I think it was Einar Mogen in Sep 1997. Rob replied and said
it was added to his "infamous" suggestion folder.
The crash_routine procedure was added to PEU at some point, I don't
remember when exactly. Anyway, Einar may have been the first to suggest
it, but I was probably the first to implement it.
--Pete E
2. RE: exception handler
Pete E wrote:
>
>
> Derek Parnell wrote:
> > Robert Craig wrote:
> > >
> > > I'm ready to implement the global exception handler concept.
> >
> > YEAH!!! (First recorded suggestion in Sep 1999 by Pete Eberlein)
>
> Actually, I think it was Einar Mogen in Sep 1997. Rob replied and said
> it was added to his "infamous" suggestion folder.
Ouch! You're right. Seven years ago!
> The crash_routine procedure was added to PEU at some point, I don't
> remember when exactly. Anyway, Einar may have been the first to suggest
> it, but I was probably the first to implement it.
Let's hope not the last, eh? 
--
Derek Parnell
Melbourne, Australia
3. RE: exception handler
Derek Parnell wrote:
>
> Pete E wrote:
>
> > The crash_routine procedure was added to PEU at some point, I don't
> > remember when exactly. Anyway, Einar may have been the first to suggest
> > it, but I was probably the first to implement it.
>
> Let's hope not the last, eh?
>
Nope, it's in my modified interpreter... 
Matt Lewis
4. RE: exception handler
I would like to suggest something along the lines of a Basic I've been
using for a long time. It seems to work well.
on Error goto xxxxx (a labeled line)
then several items were available..
1. the line which caused the problem
2. the error code that occurred (i.e file not open. divide by zero, etc)
then you could decide what to do
abort the run or "resume xxxxx " a labeled line....
In euphoria it could be similar to the trace method
"with error" then onError("yourErrorRoutine")
onError("yourErrorRoutine") would set the routine to handle the error.
this could be reset in the program to different routines to handle the
exceptions as needed. Then after fixing the problem (if possible) there
needs to be a "resume" at the next statement. At least your program
could display a resonable explanation to the user, saves what it needs, etc.
I'm certainly not a systems guy, hope this makes some sense
george
5. RE: exception handler
For the global exception handler, I really
don't want to support the resumption of the program
from the point where the error occured.
I have numerous optimizations in the Translator,
and a couple in the interpreter, that would be ruined
by this. It would mean the normal program control flow
could be broken at any moment. The Translator
could not make the very basic assumption that a
statement will be executed after the preceding statement,
without the possibility that all kinds of stuff
will suddenly change due to an exception,
e.g. global variable values.
I can handle jumping into a crash routine, but not
returning to the point of the exception and
continuing. It would be too unreliable.
Even with all optimizations turned off, I suspect
the program would have difficulty in most cases
trying to continue, e.g. if there was an uninitialized
variable, a subscript out of bounds, etc. In most cases
it doesn't seem likely that your handler would be able
to come up with a good variable value that would let your
program continue safely and productively.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. RE: exception handler
Robert Craig wrote:
>
> For the global exception handler, I really
> don't want to support the resumption of the program
> from the point where the error occured.
>
> I have numerous optimizations in the Translator,
> and a couple in the interpreter, that would be ruined
> by this. It would mean the normal program control flow
> could be broken at any moment. The Translator
> could not make the very basic assumption that a
> statement will be executed after the preceding statement,
> without the possibility that all kinds of stuff
> will suddenly change due to an exception,
> e.g. global variable values.
> I can handle jumping into a crash routine, but not
> returning to the point of the exception and
> continuing. It would be too unreliable.
>
> Even with all optimizations turned off, I suspect
> the program would have difficulty in most cases
> trying to continue, e.g. if there was an uninitialized
> variable, a subscript out of bounds, etc. In most cases
> it doesn't seem likely that your handler would be able
> to come up with a good variable value that would let your
> program continue safely and productively.
That's fine. Any improvement is welcome.
I suggest you call it "improved crash handling",
rather than "exception handling", however. That would
be more accurate.
Irv
7. RE: exception handler
Robert Craig wrote:
>
> For the global exception handler, I really
> don't want to support the resumption of the program
> from the point where the error occured.
Fine. I can live with that. In my mind, its primary purpose is so that
the application can perform some cleaning up *just* prior to an abnormal
termination.
--
Derek Parnell
Melbourne, Australia
