1. "safer" Euphoria
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Jul 13, 1998
- 518 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
2. Re: "safer" Euphoria
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jul 13, 1998
- 503 views
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
- 519 views
- 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
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Jul 13, 1998
- 489 views
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
- 497 views
- 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
- 500 views
- 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
- Posted by Irv <irv at ELLIJAY.COM> Jul 14, 1998
- 483 views
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