"safer" Euphoria

new topic     » topic index » view thread      » older message » newer message

[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

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu