1. Error Handling
As a library programmer, I have done quite a few unreleased,
it would be really nice to have a way of sending a special number to abort to
indicate the type
of error. Like the magic number previously suggested, but perhaps a different
number for
different types of number.
Abort would become
procedure abort( integer number )
if number < 0 then
display crash message
write to crash file
abort with 256 + number*-1
end if
abort with number
end procedure
each magic number would have a set standard meaning eg
-1 other error
-2 invalid subscript
-3 not an atom
-4 invalid routine id etc
That way te interpreter/library would deal with the error properly displaying te
correct
message.
-------------------------
Sincerely,
Mathew Hounsell
mat.hounsell at excite.com
2. Error Handling
I had written a simple Windows game, and was showing it off to various
people. Naturally, it crashed and burned - especially on NT machines. Up
popped the console, spewing a traceback, and an EX.ERR appeard on the
desktop. While this information was useful to me, it's not the sort of thing
I'd want the user to ever see.
I've written another small Euphoria program that will be used in front of my
entire division. I'd hate to see it go down in flames in front of all those
people. Naturally, I've checked it for errors, but I'm no Knuth - there are
bound to be error lurking in the code.
For this reason, I never use Euphoria's custom types. It's akin to using
ASSERTS in C - great for testing code, but you don't want them in the
release code. Euphoria has all these great tools for catching bugs - but
nothing for recovering from them at runtime.
This is a Bad Thing, because it leads to people losing their work, or
programs stopping which could potentially recover.
In contrast, almost all the 'modern' languages (such as Java or Python) have
some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
statement. While I've never really been a fan of this sort of thing, it
serves an important function: it makes better code.
In the past, I've lobbied for something like this:
crash_routine = routine_id("MyCrashRoutine")
This way, you could at least save the user's valuable data, so they don't
lose all their work.
I still think this sort of thing would be good, but I think we can do
better. Imagine that we had a 'on error' routine for functions and
procedures. If a 'fatal' error is encountered, Euphoria branches to that
clause:
function my_function
-- code goes here
on error do
-- recover from error
end procedure
If there were no recovery routine for the current routine, Euphoria pop it's
return stack until it encountered one. So if there were no recovery routines
at all, it would simply fail as it currently does. If you wanted to be lazy
(like me), you could just put a single recovery routine in the top level
procedure:
procedure main()
-- code goes here
on error do
-- save the data file and shut down
end procedure
Unlike crash_routine, the 'on error' clause would allow the routine to
recover from the error. This means that programs wouldn't come crashing to a
halt. You could control exactly how fine a level of control you wanted.
Comments?
-- David Cuny
3. Re: Error Handling
Excellent David. Exception handling under the control of the application is
the highest priority enhancement required in Euphoria, then comes namespace
resolution, and the 'C' translator is not a priority at all for me.
If I can add to David's excellent suggestion (quoted in full below), the
application might need to know exactly which exception occurred to trigger
the "on error do" block. So something like Basic's "err" or C's "errno"
could be set by Euphoria just prior to invoking the "on error" block. Also,
the code in there might need a way to resume execution or to retry the
statement that caused it. This is sounding a lot like Basic's error handling
now. But a "resume" and a "retry" statement could be needed.
Still another idea would be to allow application generated exceptions to be
handled in the same manner. Maybe via a "raise <exceptionnumber>" statement.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
> I had written a simple Windows game, and was showing it off to various
> people. Naturally, it crashed and burned - especially on NT machines. Up
> popped the console, spewing a traceback, and an EX.ERR appeard on the
> desktop. While this information was useful to me, it's not the sort of
thing
> I'd want the user to ever see.
>
> I've written another small Euphoria program that will be used in front of
my
> entire division. I'd hate to see it go down in flames in front of all
those
> people. Naturally, I've checked it for errors, but I'm no Knuth - there
are
> bound to be error lurking in the code.
>
> For this reason, I never use Euphoria's custom types. It's akin to using
> ASSERTS in C - great for testing code, but you don't want them in the
> release code. Euphoria has all these great tools for catching bugs - but
> nothing for recovering from them at runtime.
>
> This is a Bad Thing, because it leads to people losing their work, or
> programs stopping which could potentially recover.
>
> In contrast, almost all the 'modern' languages (such as Java or Python)
have
> some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
> statement. While I've never really been a fan of this sort of thing, it
> serves an important function: it makes better code.
>
> In the past, I've lobbied for something like this:
>
> crash_routine = routine_id("MyCrashRoutine")
>
> This way, you could at least save the user's valuable data, so they don't
> lose all their work.
>
> I still think this sort of thing would be good, but I think we can do
> better. Imagine that we had a 'on error' routine for functions and
> procedures. If a 'fatal' error is encountered, Euphoria branches to that
> clause:
>
> function my_function
> -- code goes here
> on error do
> -- recover from error
> end procedure
>
> If there were no recovery routine for the current routine, Euphoria pop
it's
> return stack until it encountered one. So if there were no recovery
routines
> at all, it would simply fail as it currently does. If you wanted to be
lazy
> (like me), you could just put a single recovery routine in the top level
> procedure:
>
> procedure main()
> -- code goes here
>
> on error do
> -- save the data file and shut down
>
> end procedure
>
> Unlike crash_routine, the 'on error' clause would allow the routine to
> recover from the error. This means that programs wouldn't come crashing to
a
> halt. You could control exactly how fine a level of control you wanted.
>
> Comments?
>
> -- David Cuny
4. Re: Error Handling
- Posted by lpcd at CYBER.NET.PK
Mar 17, 2001
Derek Parnell ne keha, 17/3/01 6:06 PM per, ke:
>Exception handling under the control of the application is
> the highest priority enhancement required in Euphoria
I second, third and fourth that. What I write in Euphoria runs only under NT
and Win2K. I _need_ exception handling.
Bruce.
--
"Who of us is mature enough for offspring before the offspring themselves
arrive? The value of marriage is not that adults produce children but that
children produce adults." -- Peter de Vries
5. Re: Error Handling
David Cuny writes,
> Up popped the console, spewing a traceback,
> and an EX.ERR appeard on the desktop. While
> this information was useful to me, it's not the
> sort of thing I'd want the user to ever see.
See crash_message() and crash_file()
in LIBRARY.DOC.
You can control exactly what appears on your
screen when an error occurs. You can give
your own polite, face-saving, message, with
no Euphoria error report appearing.
You can suppress the creation of ex.err, or
you can create it in a directory of your choice,
with a name of your choice.
> For this reason, I never use Euphoria's custom types.
> It's akin to using ASSERTS in C - great for testing code,
> but you don't want them in the release code.
Insert:
without type_check
when you release your code.
No user-defined type-checking will occur.
> In contrast, almost all the 'modern' languages
> (such as Java or Python) have some sort of try/fail
> mechanism.
What you are asking for now, is a full-blown
exception handling mechanism. That might be
worth doing, I'm not sure. I don't think it is the kind
of panacea for all our programming sins that you and others
are suggesting. In most cases when an error occurs
in a program, that program is skating on very thin
ice, and there is not much that you can do, or should do,
other than shut it down and get as much diagnostic
information as you can get. Soldiering on in the face
subscript violations, uninitialized variables etc, would
allow, in some cases, a program to complete
a logical "transaction", saving user data from
memory to disk, but in other cases it would allow
an incorrect "transaction" to be completed.
Undoing incorrect transactions is often more
difficult than re-doing transactions that were never
completed.
If exception handling is such a Good Thing, why
do I have so many Windows programs on my machine
(written in "modern languages" such as C++)
crashing with disappointing frequency,
and all I get is a message from the O/S:
"program X has attempted an illegal operation
and will be shut down". These modern programs
don't detect their own error, apologize,
or bow out gracefully.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Error Handling
Yes! This is probably the most needed feature in Euphoria. I too second,
third, etc. that.
--On Saturday, March 17, 2001 12:40:58 AM -0800 David Cuny
<dcuny at LANSET.COM> wrote:
>
>
> I had written a simple Windows game, and was showing it off to various
> people. Naturally, it crashed and burned - especially on NT machines. Up
> popped the console, spewing a traceback, and an EX.ERR appeard on the
> desktop. While this information was useful to me, it's not the sort of
> thing I'd want the user to ever see.
>
> I've written another small Euphoria program that will be used in front of
> my entire division. I'd hate to see it go down in flames in front of all
> those people. Naturally, I've checked it for errors, but I'm no Knuth -
> there are bound to be error lurking in the code.
>
> For this reason, I never use Euphoria's custom types. It's akin to using
> ASSERTS in C - great for testing code, but you don't want them in the
> release code. Euphoria has all these great tools for catching bugs - but
> nothing for recovering from them at runtime.
>
> This is a Bad Thing, because it leads to people losing their work, or
> programs stopping which could potentially recover.
>
> In contrast, almost all the 'modern' languages (such as Java or Python)
> have some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
> statement. While I've never really been a fan of this sort of thing, it
> serves an important function: it makes better code.
>
> In the past, I've lobbied for something like this:
>
> crash_routine = routine_id("MyCrashRoutine")
>
> This way, you could at least save the user's valuable data, so they don't
> lose all their work.
>
> I still think this sort of thing would be good, but I think we can do
> better. Imagine that we had a 'on error' routine for functions and
> procedures. If a 'fatal' error is encountered, Euphoria branches to that
> clause:
>
> function my_function
> -- code goes here
> on error do
> -- recover from error
> end procedure
>
> If there were no recovery routine for the current routine, Euphoria pop
> it's return stack until it encountered one. So if there were no recovery
> routines at all, it would simply fail as it currently does. If you wanted
> to be lazy (like me), you could just put a single recovery routine in the
> top level procedure:
>
> procedure main()
> -- code goes here
>
> on error do
> -- save the data file and shut down
>
> end procedure
>
> Unlike crash_routine, the 'on error' clause would allow the routine to
> recover from the error. This means that programs wouldn't come crashing
> to a halt. You could control exactly how fine a level of control you
> wanted.
>
> Comments?
>
> -- David Cuny
>
>
>
>
7. Re: Error Handling
Robert Craig wrote:
First, thanks for considering the idea. I'm not trying to get into an
extended debate, I just thought I'd hit on a couple of points. Feel free not
to reply. 
> You can control exactly what appears
> on your screen when an error occurs.
Euphoria's current behavior is to halt in a controlled manner, and offer the
option for a traceback and an error message. This is great for debugging.
And yes, I know that it can all be suppressed.
I'm glad these options are available. It would be nice if, under Windows,
the error message appeared in a message box dialog instead of the console. A
console window is a disconcerting thing to show a user!
But I'm getting off track.
The point I was trying to make was that there are quite a number of features
in Euphoria that support trapping and tracing run-time errors. In contrast,
there aren't any that support *recovering* from a run-time error.
Unlike many other interpreted languages, Euphoria tends to be very strict
about what it allows, so Euphoria is likely to catch an error before it
trashes the code.
And unlike many other languages, Euphoria only passes by value, so errors in
routines tend to be isolated (although globals and module-level varibles can
still be accessed).
I agree with your reservations - I'm not entirely convinced that Euphoria
should try to *recover* from errors. Then again, I'm not entirely convinced
it's a bad idea.
> "program X has attempted an illegal operation
> and will be shut down".
Apples and oranges. I've gotten plenty of 'illegal operation' errors in
Euphoria. It's not C++ or Euphoria's fault; it's just the nature of
interfacing with Windows. Access non-allocated memory and go to jail.
I'm talking about the sort of thing error that Euphoria currently traps.
Like Java, Python and QBasic, Euphoria is interpreted. It's not at the mercy
of blind machine code instructions. It can trap errors that shut down
compiled languages.
No, there isn't any magic. The best way to ensure programs not failing code
defensively, and to test, test, and test some more. Still, any tool that
makes my code a bit more bulletproof seems worth considering.
Thanks!
-- David Cuny
8. Re: Error Handling
From: David Cuny <dcuny at LANSET.COM>
...
> For this reason, I never use Euphoria's custom types. It's akin to using
> ASSERTS in C - great for testing code, but you don't want them in the
> release code. Euphoria has all these great tools for catching bugs - but
> nothing for recovering from them at runtime.
>
> This is a Bad Thing, because it leads to people losing their work, or
> programs stopping which could potentially recover.
>
> In contrast, almost all the 'modern' languages (such as Java or Python)
have
> some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
> statement. While I've never really been a fan of this sort of thing, it
> serves an important function: it makes better code.
>
> In the past, I've lobbied for something like this:
>
> crash_routine = routine_id("MyCrashRoutine")
>
> This way, you could at least save the user's valuable data, so they don't
> lose all their work.
>
> I still think this sort of thing would be good, but I think we can do
> better. Imagine that we had a 'on error' routine for functions and
> procedures. If a 'fatal' error is encountered, Euphoria branches to that
> clause:
>
> If there were no recovery routine for the current routine, Euphoria pop
it's
> return stack until it encountered one. So if there were no recovery
routines
> at all, it would simply fail as it currently does. If you wanted to be
lazy
> (like me), you could just put a single recovery routine in the top level
> procedure:
>
> Unlike crash_routine, the 'on error' clause would allow the routine to
> recover from the error. This means that programs wouldn't come crashing to
a
> halt. You could control exactly how fine a level of control you wanted.
>
> Comments?
That's what I always wished type() could do; instead of just
unceremoniously ending the program;
you would have the option to fix the problem and continue on if you wished:
A simple example:
type hour(object x)
if x < 0 and x < 25 then return x
else
-- a routine to do what you want, for example, show a message and ask user
to repeat
-- his entry with a valid hour.
-- or, just set x to a safe value, etc.
Using type in this way would be more versatile than an ON_ERROR, which has
to be
changed frequently to reflect the possible error/recovery conditions. Type
would also
be able to catch and differentiate between possible mutliple errors:
type hours(object x)
if hours < 0 or hours > 40 then ....fix'em or ask for user to do so
else return hours
...
type rate (object x)
if not atom(x) then ....error routine
elsif x < minimum_wage then ...error routine, or set x = minimum_wage
elsif x > bosses_wage then ...you're fired routine
else return x
..
function payamount (hours worked, rate dollars)
This function would be assured that both values passed to it were ok,
and any variables defined as hours or rate would be protected automatically
no matter where in the program they appeared.
Regards,
Irv
9. Re: Error Handling
From: Robert Craig <rds at RapidEuphoria.com>
>
> What you are asking for now, is a full-blown
> exception handling mechanism. That might be
> worth doing, I'm not sure. I don't think it is the kind
> of panacea for all our programming sins that you and others
> are suggesting. In most cases when an error occurs
> in a program, that program is skating on very thin
> ice, and there is not much that you can do, or should do,
> other than shut it down and get as much diagnostic
> information as you can get. Soldiering on in the face
> subscript violations, uninitialized variables etc, would
> allow, in some cases, a program to complete
> a logical "transaction", saving user data from
> memory to disk, but in other cases it would allow
> an incorrect "transaction" to be completed.
> Undoing incorrect transactions is often more
> difficult than re-doing transactions that were never
> completed.
There's a certain elegance that could result from implementing
type() properly.
Since type() checks upon each and every assignment, that means
you only have to declare a handler once for each class of variable you
want to monitor, and your work is done, Wherever you declare an instance
of that variable type, the checking and recovery routines are automatically
in
place.
The alternative is to call a function with each and every assignment:
x = CheckValidHours(y) -- for an assignment.
x = CheckValidHours(get_number(work_hours)) -- for input
The problem with this is obvious; code bloat. It gets messy very quickly,
whereas, if type() operated as it should, this would be simple and
automatic.
x = get_number(work_hours)
Remember, once our programs are debugged, we are still at the mercy of
whoever is _using_ the program! Writing reams of code to check for every
conceivable
input error and subsequent math error that might result from various
unexpected combinations of that input is neither elegant or efficient.
There should be an easier way.
Regards,
Irv
10. Re: Error Handling
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 17, 2001 3:40 AM
Subject: Error Handling
> I had written a simple Windows game, and was showing it off to various
> people. Naturally, it crashed and burned - especially on NT machines. Up
> popped the console, spewing a traceback, and an EX.ERR appeard on the
> desktop. While this information was useful to me, it's not the sort of
thing
> I'd want the user to ever see.
>
> I've written another small Euphoria program that will be used in front of
my
> entire division. I'd hate to see it go down in flames in front of all
those
> people. Naturally, I've checked it for errors, but I'm no Knuth - there
are
> bound to be error lurking in the code.
>
> For this reason, I never use Euphoria's custom types. It's akin to using
> ASSERTS in C - great for testing code, but you don't want them in the
> release code. Euphoria has all these great tools for catching bugs - but
> nothing for recovering from them at runtime.
I agree, except I don't think recovering from such an error at runtime is
such a good idea. In my opinion, asserts and other similar debugging
techniques should be used to find errors when developing the program, and
then turned off once the program is supposed to be stable. In Euphoria, you
could still use the custom types then just do without type_check when the
program is suppsoed to be stable.
> This is a Bad Thing, because it leads to people losing their work, or
> programs stopping which could potentially recover.
If the program fails on an assertion or type_check, it's probably
sufficiently messed up to have little chance for a simple recovery.
Meanwhile, adding such error handling would clutter up the language and the
code, and it would be very difficult to recover. However, what could be done
I suppose is to write the value of every variable and the entire call stack
to a file which one could then debug and extract any recoverable data from i
t. Perhaps a debugging version of the interpreter could write a trace file
of every statement so you can debug first using type checks etc., then run
it through with the trace file so if it crashes you can find out exactly
where and why, then when you're certain everything is fixed disable the type
checks and the trace file.
> In contrast, almost all the 'modern' languages (such as Java or Python)
have
> some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
> statement. While I've never really been a fan of this sort of thing, it
> serves an important function: it makes better code.
The only reason I've ever used the On Error in basic, or exceptions in Java
are for unexpected errors. For example, I use On Error in some of my Basic
programs in case it can't open a file, for example (since Basic doesn't
return -1 if there's a problem opening a file.) In Java, I'd use exceptions.
I prefer either using exceptions or error codes, since then you can tell
exactly what failed and sometimes why. In my opinion, they're both cleaner.
> In the past, I've lobbied for something like this:
>
> crash_routine = routine_id("MyCrashRoutine")
>
> This way, you could at least save the user's valuable data, so they don't
> lose all their work.
>
> I still think this sort of thing would be good, but I think we can do
> better. Imagine that we had a 'on error' routine for functions and
> procedures. If a 'fatal' error is encountered, Euphoria branches to that
> clause:
>
> function my_function
> -- code goes here
> on error do
> -- recover from error
> end procedure
>
> If there were no recovery routine for the current routine, Euphoria pop
it's
> return stack until it encountered one. So if there were no recovery
routines
> at all, it would simply fail as it currently does. If you wanted to be
lazy
> (like me), you could just put a single recovery routine in the top level
> procedure:
>
> procedure main()
> -- code goes here
>
> on error do
> -- save the data file and shut down
>
> end procedure
>
> Unlike crash_routine, the 'on error' clause would allow the routine to
> recover from the error. This means that programs wouldn't come crashing to
a
> halt. You could control exactly how fine a level of control you wanted.
>
> Comments?
>
> -- David Cuny
I think that generally, fatal errors are very difficult to recover from -
especially if you don't know where the program failed or why. The fatal
error might be due to a mistake many statements back, and that mistake might
have messed up the data so that it is impossible to recover from it.
Jeff Fielding
11. Re: Error Handling
I would rather use simple error return codes, like for open. I think, for
example, that this:
integer fn
fn = open("thefile","w")
if fn = -1 then
-- do something
end if
-- a bunch of statements here
Looks a lot better than:
integer fn
fn = open("thefile","w")
-- A bunch of statements here
on error do
-- do something
Jeff Fielding
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 17, 2001 8:06 AM
Subject: Re: Error Handling
> Excellent David. Exception handling under the control of the application
is
> the highest priority enhancement required in Euphoria, then comes
namespace
> resolution, and the 'C' translator is not a priority at all for me.
>
> If I can add to David's excellent suggestion (quoted in full below), the
> application might need to know exactly which exception occurred to trigger
> the "on error do" block. So something like Basic's "err" or C's "errno"
> could be set by Euphoria just prior to invoking the "on error" block.
Also,
> the code in there might need a way to resume execution or to retry the
> statement that caused it. This is sounding a lot like Basic's error
handling
> now. But a "resume" and a "retry" statement could be needed.
>
> Still another idea would be to allow application generated exceptions to
be
> handled in the same manner. Maybe via a "raise <exceptionnumber>"
statement.
>
> ------
> Derek Parnell
> Melbourne, Australia
> "To finish a job quickly, go slower."
12. Re: Error Handling
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 17, 2001 5:26 PM
Subject: Re: Error Handling
> That's what I always wished type() could do; instead of just
> unceremoniously ending the program;
> you would have the option to fix the problem and continue on if you
wished:
>
> A simple example:
> type hour(object x)
> if x < 0 and x < 25 then return x
> else
> -- a routine to do what you want, for example, show a message and ask user
> to repeat
> -- his entry with a valid hour.
> -- or, just set x to a safe value, etc.
My suggestion is not to put user input in a type-checked variable
immediately. Instead, check it first (using the type-check routine as a
function) and if it returns 0, then ask the user to re-enter the value. If
you have the program ask the user to re-enter the value every time there's a
type-check error, what happens when the user entered a perfectly valid value
and it's your program that messed up. And what if you made the form that
asked for the value disappear before the error so there's no way to reenter
the value?
>
> Using type in this way would be more versatile than an ON_ERROR, which has
> to be
> changed frequently to reflect the possible error/recovery conditions. Type
> would also
> be able to catch and differentiate between possible mutliple errors:
>
> type hours(object x)
> if hours < 0 or hours > 40 then ....fix'em or ask for user to do so
> else return hours
> ....
> type rate (object x)
> if not atom(x) then ....error routine
> elsif x < minimum_wage then ...error routine, or set x = minimum_wage
> elsif x > bosses_wage then ...you're fired routine
> else return x
> ...
> function payamount (hours worked, rate dollars)
>
> This function would be assured that both values passed to it were ok,
> and any variables defined as hours or rate would be protected
automatically
> no matter where in the program they appeared.
>
> Regards,
> Irv
13. Re: Error Handling
Jeff wrote:
> I would rather use simple error return codes, like for open. I think, for
> example, that this:
>
> integer fn
> fn = open("thefile","w")
> if fn = -1 then
> -- do something
> end if
> -- a bunch of statements here
>
> Looks a lot better than:
>
> integer fn
> fn = open("thefile","w")
> -- A bunch of statements here
> on error do
> -- do something
>
I've written some programs using a flavour of Pick Basic. Many of its
statements had the syntax of ...
<KEYWORD> <PARAMS>
ON ERROR <statements>
ELSE <statements>
END <KEYWORD>
such as
OPEN "thefile.e" FOR OUTPUT
ON ERROR
PRINT "File Failed to open"
END OPEN
I hated using it but after a while it was occasionally useful. But I
digress.
There are problems with error return codes.
Firstly, it only applies to routines that return stuff - namely functions.
Secondly, functions are usually designed to return something useful, which
means that if they can return either an error code or a non-error value, the
error code(s) must not be from the same set of values that non-error values
belong to. This can often be designed, but not for everything. A function
that is meant to return a string finds it hard to return an error code as
well. Look at how awkward Euphoria's value() function is. A normal return
value and an error code are from the same set so it must return a sequence.
To do that it means you have to do an assignment first then a test for
errors then another assignment! Not a good way to do things.
Thirdly, some errors occur in expressions (eg Divide by zero), and there is
nothing to return an error code when that happens.
Imaging if we could do something like this ....
----------------
function value(sequence text)
atom thenumber
for i = 1 to length(text) do
. . .
if text[i] = badchar then
raise #80001 with {i}
end if
if text[i] = anotherdot then
raise #80002 with {i}
end if
end for
return thenumber
end function
atom v
sequence text
v = value(text)
if exception then
if errno = #80002 then
printf (1, "Extra dot in \"%s\" at position %d", {text, errdata[i]})
else
printf (1, "Bad character at position %d in \"%s\"", {errdata[i],
text})
end if
end if
-------------------
or even ...
score = sqrt((sideA * sideB)) / Questions
if exception then
if errno = ZeroDivide then
-- Ignore this result
score = 0
else
printf(1, "Fatal error #%d", {errno})
abort(1)
end if
end if
and of course ...
-- turn off exception handling
without exceptions
-- turn on exception handling
with exceptions
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
14. Re: Error Handling
David Cuny wrote:
> to be lazy (like me), you could just put a single
> recovery routine in the
> top level procedure:
>
> procedure main()
> -- code goes here
>
> on error do
> -- save the data file and shut down
>
> end procedure
>
> Comments?
Similar "on error goto" statement was useful
for me (almost just and only) when I didn't
know what was wrong in my algorithms realised
in the QB programs and I wanted to go some
steps more in the job without immediate hard
corrections.
The second and last kind of these things was running
the program on the unknown machine - for example,
automated selection of the right graphics mode with
*statement* not *function* SCREEN like this:
'-------basic code
on error goto 911
SCREEN 13 'if there is no this mode on machine,
' error,jump to 911 mark
'if there is this mode on machine,
' no error, jump to 912 mark
goto 912
911
SCREEN 1
912
'-------end of basic code
But there are no standard *functions* like
i = graphics_mode(257)
or
i = open ("file", "wb")
in that basics, same as other robust
Euphoria features for debugging and
running robust programs on any machine.
Basics (and other *slangs* - sorry, just
a bad but innocent sailor's joke just use
primitive universal statement "on error goto"
instead of Euphoria's concrete powerful
functions.
Basics *allow* errors and stop program
in that places where Euphoria's function
just returnes -1 or 0.
What an ERROR exactly?
Do you khow ?
Or you don't want to know ?
If *you* don't know then what
will do *your program*?
The *next* error instead recovery
under your *unknown* commands
and so on?
And how long time ?
Well, if you know -- then why does
this bug sit in your program ?
Do you see - questions, not answers ?
But there may be two useful things:
first - under DOS, when compiled Eu2C
program runs with trace, *on real crash*
not *exit on error*, for safely *closing*
without damage of ctrace.out file when
ctrl+alt+del (or Reset button - he he he)
struck -- but only for program debugging
with Beta translator on plain DOS
and Beta translator debugging. :-{)
Second - to save, not delete,
the swap file on running off memory
under plain DOS to see the content
and the size of this file for
more information about bug, same
may be about more wide data
dumping in ex.err, on each error,
when hypothetical "with_wide_data_dump"
option is selected in the main
program file.
David knows what data he wants to save,
yes David?
But the first thing is the OS's, and BIOS's,
and machine's duty, not Euphoria's, while the
second one may be a pure Euphoria's duty.
I am *very lazy* programmer (see contrib.htm
on the RDS site) and I don't want at all
"on error do" in Euphoria, because of I know
that I must to know my program as well as
I can know *my* program, and Euphoria, just
without ON ERROR DO or GOTO, only helps me
to make my programs well documented, debugged
and robust ones.
Yes, I am lazy, but I don't want the old and
white bugs each behind of each "on error"
statement in my program or all behind the
single "on error" statement in the main
procedure.
And Euphoria works for me and helps me.
We all just don't know or don't uderstand or
don't use or don't remember well enough
Euphoria's simple power sometimes, I think. No ?
Regards,
Igor Kachan
kinz at peterlink.ru
15. Re: Error Handling
Derek Parnell wrote:
> v = value(text)
> if exception then
> if errno = #80002 then
> printf (...)
> else
> printf (...)
> end if
> end if
>From a grammar point of view, the 'if' looks like a normal if. Something
like:
<var> = <expr>
on exception do
<code>
end exeception
would be more clear for the interpreter. It would also be more compatible
with existing code. So your example might look like:
v = value( text )
on exception do
printf( 1, err_msg( errno ) )
end exception
The other problem is that this only catches errors on functions, not
procedures.
A try/fail sort of structure:
try
<code>
on exception do
<code>
end try
has the advantage of encompassing an arbitrarily large or small amount of
code. For example, you could catch errors at the single statement level:
try v = value( text )
on exception do
printf( 1, err_msg( errno ) )
end try
to the macro level:
procedure main()
try
... lots of code here ...
on exception do
... error recovery here ...
end try
end procedure
However, this would be a major conceptual change for Euphoria, because some
operations (like bad indexes or file numbers) cause Euphoria to shut down,
instead of setting an error message. Of course, Euphoria could behave
*exactly* the same as it currently does if there are no exception handlers
in place.
-- David Cuny
16. Re: Error Handling
Jeffrey Fielding wrote:
>I would rather use simple error return codes, like for open.
I was browsing through 'The Practice of Programming' by Kernighan and Pike,
and the topic of exception handling came up. My recollection was that:
1. Exceptions be limited to real exceptions, like floating point errors.
Files not opening are not exceptions. Languages (like Java) that use
exceptions tend to go overboard and make everything an exception. This makes
for very unclear code.
2 The user should be offered the chance to run some recovery routine. They
weren't entirely enthusiastic about the idea of the program attempting to
continue after a *true* exception, but they didn't disallow it entirely.
Just muddying the waters. 
-- David Cuny
