--- Steven McPhelan <[EMAIL PROTECTED]> wrote: > What does your application do when it does encounter a <null> > subscript? I > think that is the more important problem than a M error thrown when > it > happens. In production software, why would your application > encounter a > <null> subscript in the first place? Usually it is the result of bad > data > or missing data in the database. If your application was expecting a > valid > reference at that point, I presume that the data that populated those > subscripts was critical or important to the integrity of the > database.
I've heard this argument many times, but I don't buy it. Catching and handling errors in a controlled manner (rather than just letting an application crash, with possibly unpredictable results) isn't "hiding" tyhe error, it's a matter of trying to limit the damage that could be caused by an uncaught error. Of course, it's possible to be irresponsible and "catch and ignore" errors, but that's not what I'm advocating. Sorry to be so cranky, but this "let it happen" attitude (which is not necessarily your position) has done VistA a lot of harm. > > Protecting against every possible computer error in software as large > as > VistA is not always possible. If the application is well designed > then you > should never experience <null> subscripts. So why burden the source > code > with redundent checks for conditions that should never occur. Funny word, that "should". >Of > course > things happen. But that is what the error trap and the error log are > for. It may be true that 80-90% of the time, errors are caught simply for reporting purposes, but not always. Symbol table pollution in long running processes can be a real problem. Not only does the SAC require that you leave the symbol table unaltered, but you may not be the only one you end of hurting if you leave stray variable around. I've seen applications crash because of errors that occured in entirely different tasks/interfaces, possibly long ago. > The user gets notified of a M error. It seems very bad to the end > user. Yes, and many people overreact to trivial errors, and take a cavalier attitude towards serious ones. The user doesn't always know the difference. > But then you have a log to reference to fix those database errors in > the > first place. If the problem recurs after x number of times then you > have a > clue that there may be some software bug somewhere. It is always a > trade > off on how to handle potential problems which occur seldom or less. True enough. It's a bit like "the" classic optimization error: spending all your time trying to optimize what is already efficient, and failing to even notice the real bottlenecks. > > I cannot imagine how large the source code for VistA would be if > every > application always checked for valid information every time even > though the > application was designed with the intent that that valid information > would > always be present. > I wonder. Could it be be 30% larger? 50% larger? Even 100% larger would quite possibly be reasonable. But it's not the problems we've already thought of that tend to bite us. I'm only one programmer, but I always try to check for error conditions, even "impossible" ones, and write code that responds intelligently when problems occur. === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
