"safer" Euphoria
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Jul 13, 1998
- 526 views
[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