1. RE: Error Handling
Hi Dave and others,
David Cuny 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
>
>
Notice i quoted the WHOLE post you wrote, even though it was a
lllllllooooooonnnnnnngggggggggg one?
Thats in the great hopes that Rob will read it SOMEDAY 
Peeve#1:
Actually, i've written programs that were 99.99 percent error
free, sent them to people who found the .01 percent while
wondering what the heck the program was printing to the screen.
Once they see 'strange and bewildering' stuff like that they
dont want to be bothered with the program again, even if its
a really rare occurance. Presently, the only way to avoid this
is to be a 'super error conscientious' programmer. While this
may be possible in principle, is it really practical and is
that really what a VHLL should be like? I dont think so.
Q. What ever happened to 'very high level language' ?
A. Part of its 'high', and part of it is really, really,
really, really, 'low'.
Give me one simple "crash include" or "crash routine_id"
and i can change all that forever.
Thats mainly why i havent invested in the registered version yet.
If im going to invest in anything, its going to have to get real.
Peeve#2:
Once upon a time, in a virtual memory far, far, away,
bindw used to be able to convert function and procedure
names into just a few letters, saving space in larger
programs and raising the security of the program making
reverse engineering that much harder. What the heck
happened to that???? Now 'clear_routines' (which you have to
type out, by the way, since bindw cant detect the fact that
routine id had been used??) also seems to 'clear' that
feature out also.
Q. Does 'updating the software' mean making it better and
easier to use?
A. Well some things come out better, and some things come out
worse, and still yet some other things dont work anymore.
All and all the language has improved overall since i first
started using it, but some of the pitfalls are just silly.
How about we see that improve?
Im sorry to see so much work being done on
the "C translator", because i can see its taking
time away from getting the language really good.
Now improvements in the language will take three times as
long because everything new has to be included in the
"translator" and tested with the "translator" as well.
Ive gotten programs to work 100 percent error free, but it
usually takes a lot of testing when the program is really
large. At least with a crash call you can always blame the
user in a polite message box
Hope to see these improvements before any others.
--Al
2. RE: Error Handling
G'day all
Derek Parnell wrote:
>
> 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.
> <snip>
>
I believe sensible error handling is one of Eu's great flaws. However,
Derek's approach requires lots of programmer-supplied error handlers
scattered throughout the code. This can get fairly tedious after a
while. I much prefer David Cuny's appoach of a global onError handler,
especially if that can be backed up with a bit of help from the Eu
interpreter.
The interpreter "knows" when an error has occurred, and even tells you
about it. Wouldn't it be nice if the interpreter tested for an onError
handler, then passed the handler a couple of "system" variables like
$errnum and $errmsg, and gave the programmer the option of handling the
error? Of course, if the dying program didn't have an onError handler,
the interpreter could just do what it does now, so there'd be no
breakage of existing code. And if the error was a real nasty, the
programmer could always abort(1) anyway.
Scoping multiple onError handlers inside funcions/procedures, include
files, etc, would be nice, too.
Regards
Tony
