To: | Barry Kelly |
From: | "Kristofer Skaug" |
Newsgroup: | borland.public.delphi.objectpascal |
19-Aug-2001
Re: Exceptions vs Error codes"Barry Kelly" <✉eircom.net> wrote in message news:✉4ax.com... > You show me where the reasoning breaks down: > <...> > * If you see virtue in ignoring error conditions, you > aren't surviving errors - you are ignoring them. > (this point follows directly) > > I ask for an integer. The user enters "x". > > * Does my StrToInt routine have a fault for not converting it? No: A fault would be, if StrToInt returned some value without somehow indicating that it is invalid. > * Is the input faulty? > > I fear we're losing the semantics here; we need to define "failure", > "fault" and responsibility for input and correction more clearly in > order to say what's best for each case. OK let me take a swipe at that: To begin with the easy part: input validation - this isn't software errors IMO. The input is generated by a human operator or another application or comes from a data file. If this input is not conformant to that expected by the program, the program shall robustly reject that input and - if possible - allow other input data to be presented. This is, in my view, *not* related to error handling as such but rather a normal function of any program which takes input from external sources. An 'error' in this context (i.e. from the internal application software point of view) would only be if the program failed to trap bad input data, or unexpectedly reject valid input data; i.e. the application is not fulfilling its 'contract' or specification. If the user types an 'x' where '0'-'9' was expected, it is a user error but not an error in the application as such (i.e. the application did nothing 'wrong'). > I have an editor. It's called PFE - Programmer's File Editor. .... > <snip> ... but that editor continuing and surviving > long enough to save its "buffer" to disk was *lethal*. The sooner it > could have crashed and alerted me, the better. > > I just don't believe in what you're advocating. Don't mind that it isn't > a good idea; it isn't even ethical. Sounds like we need a counter-example: One of my company's software products supports communication links with satellites while on ground, i.e. during development and testing. Those satellites cost typically 1-2 billion EUROs apiece. They are pretty vulnerable and helpless little buggers in their infancy and will fall over and cry for mummy for the silliest little reasons. While the system software engineers are uploading new and more mature software versions to their on-board computers every week, the problem is that it can take a day or more to reboot such a satellite once it's down. A surefire way of taking the satellite down is to abandon it for more than 5 minutes. A missing comm link will do that for you, unless you can somehow tell it to go to "safe mode" first, which is a hibernation state from which it will be resurrected more quickly. After a while, distrusting the satellite's maturity (self-sustainment) level, the engineers have little choice but to hit the "emergency power-off" button. > This code: > > * Loses the concept of natural return value (that is, every > function is effectively a procedure since the return value > has been hijacked for another purpose. I am afraid you close-read me too much here. This is not what I actually do, by TErrorInfo for example I was just trying to indicate a generalised "error info returned" without committing myself to a particular data type. Also, I guess more often than not, the error info is returned as a var parameter (my favorite parameter list closure phrase is 'var isOK:boolean);' - I even have a keyboard macro for this one! <g>). So I am not trying to rob functions of their natural return values. This is more the case with API related routines or custom DLL function calls. > * Requires plumbing in *every* procedure, even if it doesn't have to > do any error management itself. > > * Is trying to reinvent exceptions, but maybe you don't know that yet. See my comments on TErrorInfo above. > * Requires now partially redundant try..finally blocks for cleanup. Let's write off that on the part of a clumsy and oversimplified code example. <g>
> I wouldn't dream of letting *my* back end near the user interface. <g>
??? you lost me there, I must be getting too serious about this <g> What I meant was that, at least in all operational/control classes, I always have a messaging event which passes text information to the owner of that object, which in turn has its own event for exporting these messages again... eventually this upward chain of message passing results in a line of log text displayed in the user interface.
> > So that's why I feel also, that just passing some low level exception on
> > to BigBoss has little actual value. > > There are at least three solutions to this. <... examples noted... > Interesting techniques which can make raising exceptions "look" like error code passing. > So let the application handle the exception: <....> > At least it lets the user know that something is wrong and gives > them a clue, instead of leaving them wondering if the > printer is plugged in. OK, this wasn't the point here - I wasn't trying to advocate "leaving the user in the dark". I was trying to demonstrate that there are "errors" (leading to *exceptions*) which an application might not actually care about. Within the spec of that application, these errors are simply not relevant. We truly don't care. Period. This is not *sloppy programming*, we are *not* incurring bad states, no, we simply call some bleeping API somewhere, cross our fingers and don't care if it blows up, as long as it doesn't blow *us* up. Printing was one example. Trying to locate a default e-mail client or web browser is another example. If it's not there it's not there. Too bad. In these situations it's nice to have error codes, because you can do what you want with them. Exceptions, you *got to* catch them, or they'll wallop you. So, this puts extra constraints on your code. |