1. "safer" Euphoria
[Catching bugs vs. Saving Data]
I've been reading through "Writing Solid Code" (Steve Maguire, Microsoft
Press) to re-acquaint myself with "good programming practices" in C
code. I was pleased to see that many suggestions for debugging C code
are automatically done by Euphoria.
However, Maguire notes that the debug statements are ONLY for in-house
testing, placed in #ifdef...#endif and assert macros. There is a big
difference between the environment that the developer uses, and the code
the end user gets. For the developer, the code comes to a halt at the
first sign of a bug. For the user, the goal is to maintain the data.
The code that goes to the customers does NOT contain the traps -
instead, it contains plenty of "defensive" mechanisms, aimed at keeping
the user's data safe from the remaining bugs.
I think it is important to recognize that in the user's environment, the
important thing is not the "correctness" of the code, but the safety of
the data.
[Range Errors in Sequences]
The points where Euphoria typically detects errors in my code are with
range errors in sequences. This is not suprising, since almost all
Euphoria coding has to do with manipulating sequences.
There are a couple of reasons that I think Robert has little incentive
to put automatic range checks in:
1. Range errors are bugs.
-------------------------
I think that this is a valid reason hor halting code - but not in the
shipping release.
2. It slows down the interpreter.
---------------------------------
This is the classic safety vs. speed argument. Some applications (such
as games) are willing to accept the additional risk for speed. I think
that it should be for the user to determine which option to select.
3. 90% less bugs = 90% less registrations
-----------------------------------------
I suspect this would be the biggest reason for Robert not to have
automatic range checks.
If this is the case, then make it a registered version only option.
After all, if you are creating applications that you are shipping to
people, you probably should register.
4. It encourages bad coding practice
------------------------------------
I think that the development environment is *different* from the end
user environment, and the interpreter should recognize the difference.
It's fine to stop a program and tell the programmer that they forgot to
initialize a variable - but certainly not acceptable for an end
application.
Besides, if you post the code, the first thing someone is going to do is
run it from EX.EXE, and find the error.
[Failsafe Routines]
I've also argued that a user-defined "failsafe" routine, that would be
triggered before the code aborts, would be a good thing.
The ability to do range checks would lessen the need for a "failsafe"
routine in Euphoria, but I still think that, in the interest of saving
the user's data, such a routine would still be needed.
-- David Cuny
2. Re: "safer" Euphoria
David Cuny writes:
> [Catching bugs vs. Saving Data]
As people may have figured out by now, I am
in favor of automatically catching bugs as soon
as possible, rather than quietly ignoring them and
hoping that the program will somehow continue and
do the right thing.
As I've said before, RDS has implemented Euphoria
in such a way that the cost of subscript checking
and uninitialized variable checking are both almost zero.
An optimization that I added a few days ago has reduced
the cost of uninitialized variable checking even further.
If both of these checks could be turned off by the programmer,
the speed increase would only be on the order of 1 or 2%.
I therefore reject the notion that these checks are so
expensive that we need a way to turn them off in shippable
code.
The other argument is that stopping the program will
cause data loss. This is sometimes true. It is also sometimes
true that *not* stopping the program will cause data loss.
I'd rather lose data in a situation where I know that the
program has failed, than have my data *quietly* corrupted during
a run that appeared to be normal. I'd rather lose my editing
session, than have the editor *quietly* insert an incorrect
character into my source program. (x = x + 1 becomes x = x + 2).
I'd rather have my C compiler crash, than continue to quietly
produce slightly incorrect machine code.
> However, Maguire notes that the debug statements are
> ONLY for in-house testing, placed in #ifdef...#endif and
> assert macros.
On a compiler project I worked on several years ago, I deliberately
*left in* lots of redundant debug checks and assertions in
#ifdef code. The compiler ran 5% slower and was shipped to the customers.
This approach paid off in a big way. Users couldn't
care less about the extra 5%, but they were able to report
*meaningful* bugs back to me, which I could easily fix. Otherwise
it could have wasted days of their time and days of my time to track down
the resulting bugs in the machine code. (I also had some
extra, very expensive, checks that I only turned on for in-house
debugging).
(The debug version of Euphoria at RDS has tons of checks. The
released version has almost none, since speed is very
important.)
There are many ways of protecting a users data. For instance
an editor could save the buffer to a temp file every once in a while.
When I worked on a database management system a few years
ago, there was a carefully worked out algorithm for committing
and rolling-back records (with logs of transactions).
The software, or the machine, could crash at any point and
you wouldn't corrupt your database.
Still, I am interested in investigating a global exception
handling mechanism of some kind.
> 90% less bugs = 90% less registrations
> -----------------------------------------
> I suspect this would be the biggest reason for Robert not to have
> automatic range checks.
As a shareware author who has developed a relatively-unknown
language and interpreter, I am *really* glad that Euphoria
does a lot of run-time checking, but *not* for the reason you
suggest.
Suppose there were no run-time checks. Someone downloads
Euphoria, writes a simple program that he believes to be correct,
runs it, and *crash* - his whole system goes down in flames.
Is he going to believe that his program was at fault? Or is he
going to blame the $#%$#%!!! shareware program he just
downloaded?
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: "safer" Euphoria
- Posted by Irv <irv at ELLIJAY.COM>
Jul 13, 1998
-
Last edited Jul 14, 1998
Cuny, David wrote:
>
> [Catching bugs vs. Saving Data]
> <snip>
> I think that the development environment is *different* from the end
> user environment, and the interpreter should recognize the difference.
> It's fine to stop a program and tell the programmer that they forgot to
> initialize a variable - but certainly not acceptable for an end
> application.
>
It is different. The end user flails away at the keyboard and mouse,
entering
text where numbers should go, and dividing monthly pay by Fred. They
also
occasionally delete files at random "to clean up their disk", and then
complain
that your program "won't work". These actions are rather hard to
predict.
> [Failsafe Routines]
The problem with any "failsafe" routine is: what exactly should it do?
Stop and save the changes? Roll back to a previous state? Assume some
data
that isn't there? There's no way for anyone but the programmer to know -
based
on the exact state at the time of the error. So we're stuck with writing
input validation routines anyway.
Irv
4. Re: "safer" Euphoria
Robert replied to my suggestions:
< snip (lots of stuff I agree with) >
[New Suggestion]
I've given it a bit more thought, and have a modification of my initial
suggestion. When Euphoria sees an error, I'd like it to see it:
1. Log the error in EX.ERR
2. Execute the global exception handler (if it exists)
3. Optionally try to continue
The exception handler could be passed a value by Euphoria, indicating if
the error could be "recovered from". A "recoverable error" might be an
uninitialized variable, or an out of range index.
In order to continue, the exception handler would have to call a routine
that would pop up a dialog like this:
+----------------------------------+
| *** Really Bad Error *** |
| The program encountered a really |
| bad error. However, it was able |
| to save the file to disk. |
| |
| << Shut Down >> < Ignore > |
+----------------------------------+
The text of the dialog could be selected by the coder, and the "Ignore"
button would be optional, (but automatically dimmed if Euphoria deemed
that the error was "unrecoverable").
I like this option a lot - it gives control to the user, but makes it
impossible to hide coding bugs.
["Expensive" Code]
> I therefore reject the notion that these checks are so
> expensive that we need a way to turn them off in shippable
> code.
I didn't mean to imply that the current tests were expensive, but that
automatically "correcting" range errors would be more expensive.
But it's obviously foolish for me to make any statements about how
"expensive", "inexpensive" or "efficient" Euphoria's code may be. 
[Debugging and Knowlegeable Users]
>On a compiler project I worked on several years ago, I deliberately
>*left in* lots of redundant debug checks and assertions in
>#ifdef code. The compiler ran 5% slower and was shipped to the
customers.
>This approach paid off in a big way. Users couldn't
>care less about the extra 5%, but they were able to report
>*meaningful* bugs back to me, which I could easily fix. Otherwise
>it could have wasted days of their time and days of my time to track
down
>the resulting bugs in the machine code. (I also had some
>extra, very expensive, checks that I only turned on for in-house
>debugging).
I agree, but suspect that one of the main reasons it worked was because
your users were Knowledgeable Programmers. They understand what happened
when your compiler spit out an error condition; they appreciate that
sending in a bug report will give them a better product. They Have A
Clue.
I would guess (and risk being Very Wrong) the typical users of Euphoria
are also mostly programmers. If a Euphoria program detects an error and
shuts down (not the same as crashing), the user will understand what has
happened.
-- David Cuny
5. Re: "safer" Euphoria
- Posted by Daniel Berstein <daber at PAIR.COM>
Jul 13, 1998
-
Last edited Jul 14, 1998
-----Original Message-----
De: Cuny, David <David.Cuny at DSS.CA.GOV>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: Lunes 13 de Julio de 1998 10:16 PM
Asunto: Re: "safer" Euphoria
>The exception handler could be passed a value by Euphoria, indicating if
>the error could be "recovered from". A "recoverable error" might be an
>uninitialized variable, or an out of range index.
Uninitialized variable? I suppose you'll catch this the first time you
pre-alpha-test you program David.
Out of range index is a very difficult to interpret "bug". Why did you get
an out of range error? How much data was corrupted cause of this algorithmic
error?
>The text of the dialog could be selected by the coder, and the "Ignore"
>button would be optional, (but automatically dimmed if Euphoria deemed
>that the error was "unrecoverable").
I agree that a customizable error (crash) message is very useful, Rob
understood it and added crash_message() some time ago. Better than trying to
"predict" if the error is recoverable I think it's better to have a
crash_dump(). This last resource function would do a file dump of whatever
you want to save. Then you can ask your client to send the dump... you'll
then try to recover any information if it's corrupted. You can even provide
your software for a crash_recovery functionality that read the dump and
analize what can be done with it.
Regards,
Daniel Berstein
daber at pair.com
6. Re: "safer" Euphoria
- Posted by David Cuny <dcuny at LANSET.COM>
Jul 13, 1998
-
Last edited Jul 14, 1998
Irv wrote:
> [The user environment] is different. The end user
> flails away at the keyboard and mouse, entering
>text where numbers should go, and dividing monthly
>pay by Fred. They also occasionally delete files at
>random "to clean up their disk", and then complain
>that your program "won't work". These actions are
>rather hard to predict.
Yes, I agree. But see Alan Cooper's (software interface guru) article at:
http://www.cooper.com/articles/vbpj_ban_the_bomb.html
why "Programs should not have error messages. None. Not a single one. Ever."
Besides, these errors are not *user* errors: they are errors on the part of
the coder.
>Failsafe
In the cases that I'm talking about, there is no reason to assume that the
data is bad. Euphoria has merely determined that the instruction that it has
been requested to do -at the coder's request - is not legal. As a result, it
will *punish* the user of the code by shutting down, and the user will be
that much less happy with my program.
In a design environment, this is *excellent* behavior. In the end user
environment, it's probably *not* what you want to have happen.
With compiled code, it would be a different matter - the code is off and
running goodness-knows-what, stomping over precious memory and files. You
want the process shut down cold, before it can do any more damage, and bring
down the OS.
But Euphoria is *not* crashing - we're talking about a controlled shutdown
at this point. It's a Design Feature. Euphoria *knows* that the value is
bad, and can probably make a reasonable guess as to what an acceptable value
might be. The kind of errors I'm talking about include:
- Asking for a slice beyond the length of a sequence
- Using a variable before it's been initialized
- Moving the cursor off the screen
- Selecting an illegal color
Up to the point of the "bad" instruction (which has not yet been executed),
there is no reason to assume that the data is bad. So we have every reason
to think that it can be saved.
But beyond that, since Euphoria can make a good guess what the value *might*
be, why not let it? Obviously, it's designed otherwise, for compelling
reason:
1. Because it's an error. It's clearly in the best interest of the coder to
know where the program went wrong, but it's not so clear that bringing the
code to a halt is in the best interest in the user.
2. Because bad results will destroy the data. Possibly, but not probably.
Most of the bugs that I get in my code are sequence range errors. Nine times
out of ten, Euphoria could substitute a legal value, and the code would
continue just fine, and just fall thought at another test. In the rare cases
where it would lead to a cascade of errors, it would be clearly obvious when
it popped up error after error.
3. Because it encourages bad programming practice. If the error was handled
invisibly, I might accept that. But ominous error messages popping up are
sort of hard to hide from the end user.
I'm not advocating making the error checking any less rigorous than it is
now - only that the end user be given the option to attempt to continue past
the error. If it bombs, fine. But chances are, it won't - and the coder will
still get an error report telling exactly what went wrong. So everybody's
happy.
OK, so maybe only just me. 
-- David Cuny
7. Re: "safer" Euphoria
David Cuny wrote:
>
> Yes, I agree. But see Alan Cooper's (software interface guru) article at:
>
> http://www.cooper.com/articles/vbpj_ban_the_bomb.html
>
> why "Programs should not have error messages. None. Not a single one. Ever."
>
A nicely written article, with some ideas I can use.
Let's look at an example from yesterday:
--
User: Your program won't look up prices right!
Me: Let me see what you're working on.... hmm... what is product # 1998?
User: We don't have a product # 1998.
Me: These 5 items have product # 1998 .......
User: Oh, I wanted a date to show in that column, so I typed it in.
Me: What was there before?
User: Numbers - 153-334, stuff like that.
Me: Like product numbers?
User: Yeah. Your program doesn't look up prices right.
--
Yes. This was a coder error. Sure. I could have checked for invalid
product
numbers, right? (We DO have a product #2000. How do I check for THAT
error?)
I should add: I had already tried locking the product # column, and got
lots
of complaints along the lines of "We can't enter/change/correct a
number!"
That's why I unlocked it in the first place.
I did learn from the article, however, so my next version of the program
will run like this:
PC (User)
--
Here are some nice products. Shall I pick one at random? (No)
OK, Would you like a nice sofa? (No!)
Well, how about a chair? There are lots of nice chairs.... (NO!)
Gosh (computer humming sounds) Maybe a lamp? (At last! Yes a lamp!)
OK, (cooing sounds) I like lamp #2000, how about you? (No, I want #
156)
(computer hums a pleasant tune) Would that be # 156-A or 156-B? (B)
Thank you. B it is. Will there be anything else? (How much does it
cost?)
Oh, (another coo) I'm certain we can arrive at a mutually acceptable
price...
--
That ought to boost productivity greatly. I also liked the writer's idea
of just leaving things (like the customer name and address) blank, and
"catching the error" later.
Bruno the 350 pound shipping clerk will no doubt deliver his own unique
"error
message" at the appropriate time.
Irv
