|
Policy on exceptions: Joel or Fog Creek?
In his original bit on exceptions, Joel told what *his* policy is. The entire weblogging world took the bait and debated.
I think the more interesting question has yet to be discussed: Is this Joel's policy, or is it Fog Creek's policy? Or are those topics the same?
Joel often talks about hiring from the top 99.9% of developers. If so, those are guys with brains and strong opinions.
Joel, what happens if one of them disagrees with you?
:-)
Eric Sink
Wednesday, October 15, 2003
s/guys/guys or gals/
Eric Sink
Wednesday, October 15, 2003
Indeed, it's hard to imagine hiring the top tier of developers and getting them to agree with favoring error return codes over language-structured exception handling.
However, from what I've read here, Fog Creek's products are currently written in VB, which doesn't have Java/C++/C#-style exception handling, it has ON ERROR - so the issue probably doesn't come up.
It will be interesting to see if this issue is revisited when Fog Creek moves to .NET.
Kyle Cordes
Wednesday, October 15, 2003
I feel much more comfortable with Joel's latest post about exceptions being neither all-good nor all-bad, but something to be considered as part of the trade-offs in a design.
If somebody disagreed with me over a design decision and convinced me that it made good sense to change and had minimal impact (for me this usually means before coding's started) then I'd change it.
Better Than Being Unemployed...
Wednesday, October 15, 2003
"Indeed, it's hard to imagine hiring the top tier of developers and getting them to agree with favoring error return codes over language-structured exception handling."
Why do you say that? There were probably at least a 100:1 ratio of people who disagreed w/ Joel to those who agreed.
I think Joel's backpedaling, and ineffectively at that. Yeah, there are design tradeoffs, but the scale is not even. Exceptions provide a LOT more value than their cost, especially in languages like C# and Java where there's no scope. They are far more expensive in C++ (because of stack tracking and unwinding locals).
In C# and Java, it _is_ a no-brainer to use exceptions, and I would strongly resist any wishy-washy equivocation that suggested otherwise.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, October 15, 2003
Joel's latest post is a sign that he can't admit
when he's wrong. Maybe his role as super coder
has something to with that. The whole everything is
a tradeoff and no way is the best way line is
just that-- a line.
bitter
Wednesday, October 15, 2003
I agree. Trying to cast a discussion about exceptions as a "religious argument" is simply a way to try and avoid addressing the real issues. It's the Godwin's law of language debates. Bringing up the "religious argument" line is a way of trying to trivialize the discussion, to say that both sides are right and that there isn't a way to choose between them. For exceptions this isn't true. Whether or not to use exceptions is not a "religious argument", exceptions are a good idea introduced to solve real problems. If the language you use provides exceptions and you don't use them you are wrong, and that's really the end of it. It's not a matter of whether or not you believe in exceptions, or that you have to have faith in exceptions before they will improve your code. Formatting style, now there's a "religious argument".
Alex
Wednesday, October 15, 2003
The only thing I would say against exceptions is this: they are hard to introduce well into existing code.
Mr Jack
Wednesday, October 15, 2003
I find this all rather amusing. In my opinion, I love Java exceptions -- one of the greatest traits of the language.
C++ I'm pretty up in the air. Performance hit is significant, you run the risk of missing exceptions (do not pass go, go directly to terminate()), most C API return status codes anyway.
VB... Ha Ha Ha, people ship commercial code with that ?
mr. amusing
Wednesday, October 15, 2003
"There were probably at least a 100:1 ratio of people who disagreed w/ Joel to those who agreed."
As one who agreed with Joel and the other 1 in 100, I'd say that proves beyond any doubt that only the top 1% of developers are smart enough to buck the trend when the trend is wrong.
Dennis Atkins
Wednesday, October 15, 2003
> As one who agreed with Joel and the other 1 in 100, I'd say that proves beyond any doubt that only the top 1% of developers are smart enough to buck the trend when the trend is wrong.
This is great bravado, but poor argument.
Portabella
Wednesday, October 15, 2003
"the trend is wrong"
Structured programming is just a fad.
Object-oriented programming is just a fad.
Functional programming is just a fad.
Virtual machines are just a fad.
Extreme programming is just a fad.
Garbage collection is just a fad.
Exceptions are just a fad.
...Conversely...
Structured programming solves everything.
Object-oriented programming solve everything.
Functional programming solves everything.
Everything should be compiled to a virtual machine.
Extreme programming will guaruntee project success.
Programmers shouldn't management memory themselves.
Exceptions should be used for all error handling, always.
---
Are exceptions _in general_ bad? This has been debated for years; and even the "experts: agree it's a good thing. This is why pretty much all new languages have exceptions. In Joel's particular case, VB mixed with C++, exceptions are pretty much useless -- he'll get no argument from me.
When Joel says that _in general_ rewriting code from scatch is a bad thing -- he's right. When Joel says that _in general_ exceptions are bad -- he's wrong.
Almost Anonymous
Wednesday, October 15, 2003
Then how come in the real world I keep seeing kiosks and billboards with a blank screen that says "blah blah java blah blah exception rut time failed blah blah".
I disagree that a program should crash when an error is encountered, and yet, in the real world this is how real world java apps work. Sure, we all love the pie in the sky 'philosophies' and 'theories' and 'wouldn't it be nice if everyone would use it correctly'. Wouldn't it be great if we didn't need money? Wouldn't it be great if everybody could get along and there were no wars? Yeah, sure, but it' ain't that way in this inconvenient detail called REALITY.
Joel and another 1% of the folks posting here make a living selling their own software. These folks are the ones who know what they are talking about. I'll take a half baked 'wrong' but real life insight from Joel over a thousand textbooks by the theorists, program leads with little coding experience, trolls, and juinior programmers who know it all since they studied it in school or heard abxout it on slash dot or some blog. You either have real life experience or you don't. Joel has made several successful robust commercial products that actually sell and benefit people. His opinion counts infinitely more than those who have never created their own product and brought it to market.
Dennis Atkins
Wednesday, October 15, 2003
"Yeah, sure, but it' ain't that way in this inconvenient detail called REALITY."
Wake up on the wrong side of the bed today, Dennis?
"Then how come in the real world I keep seeing kiosks and billboards with a blank screen that says "blah blah java blah blah exception rut time failed blah blah"."
Crappy programmers abound! We all know that. In such a case, a crappy programmer ignored the error handling and the app crashed. If the same crappy programmer ignored a failed return status code, what do you think would happen?
"I disagree that a program should crash when an error is encountered, and yet, in the real world this is how real world java apps work."
If an error occurred and it's unhandled -- it's real good day if the program terminates exactly at that point, somewhat gracefully, before doing anymore damage! I don't program in Java, but that is a good thing.
"Wouldn't it be great if we didn't need money?"
Certainly... now I really have to get back to work and make some.
Almost Anonymous
Wednesday, October 15, 2003
Dennis, if the developers can't remember to
catch exceptions at some top level then
they'll never ever be able to handle all the
return codes in every module for every
statement.
son of parnas
Wednesday, October 15, 2003
Theoretically it all sounds great. In real life, exceptions create trouble.
I hear a lot of fancy talk about exceptional circumstances. Then, look at the examples on this board -- if parsing an integer from ascii and one encounters a non-integer, an exception is thrown which may terminate the program! All the user's work is lost!
Any time an error of any kind is encountered, the program should in decreasing desirability:
1) transparently correct the recoverable error
2) notify the user of the recoverable error and continue
3) notify the user a nonrecoverable error has occurred and advise they save all work immediately and restart
4) (in event of something like a stack collision or apparent memory failure) notify of error and quit, autosaving to temp files if at all possible
Unexpectedly quitting is NEVER NEVER NEVER NEVER acceptable in production code.
Here is an example of what NOT to do which just occured when I clickk on a link at the AngryCoder site only five minutes ago. This is BULLSHIT. They should not be telling me any of this, they should be saving it to a log file and taking a look at it themselves.:
General network error. Check your network documentation.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: General network error. Check your network documentation.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[SqlException: General network error. Check your network documentation.]
System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) +723
System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) +45
System.Data.SqlClient.SqlCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) +5
System.Data.Common.DbDataAdapter.FillFromCommand(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +304
System.Data.Common.DbDataAdapter.Fill(DataTable dataTable, IDbCommand command, CommandBehavior behavior) +28
System.Data.Common.DbDataAdapter.Fill(DataTable dataTable) +88
eZine.Framework.Data.Sql.Engine.GetDataTable(String Sql, String ConnectString) +81
eZine.Framework.CodeBehind.uc_book_pick_list.Page_Load(Object sender, EventArgs e) +49
System.Web.UI.Control.OnLoad(EventArgs e) +67
System.Web.UI.Control.LoadRecursive() +35
System.Web.UI.Control.LoadRecursive() +98
System.Web.UI.Control.LoadRecursive() +98
System.Web.UI.Page.ProcessRequestMain() +731
Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573
Dennis Atkins
Wednesday, October 15, 2003
I'm not sure exactly why you blame "unexpectedly quiting" and "displaying alot of debugging stuff" on exceptions?
Those things can occur with or without the presence of exceptions and really have nothing to do with them.
Almost Anonymous
Wednesday, October 15, 2003
"I'm not sure exactly why you blame "unexpectedly quiting" and "displaying alot of debugging stuff" on exceptions"
He has a point. Exceptions provide much more useful information for identifying the precise cause of the error, and the reason why the program terminated.
The real question is why anyone would object to this.
Seriously, wrap it up with automatic crash logging and reporting, a pretty dialog box that says 'your data is gone, sorry about that', and watch your product's reliability soar as you quickly eliminate all the bugs that made it past QA.
That's simply intolerable - weird crashes caused by data being corrupted by an earlier error that wasn't handled properly are so much better. Why would anyone prefer an automatic error report to an unhelpful 'access violation' or 'illegal operation' message? :)
andrew m
Wednesday, October 15, 2003
Unhandled exceptions cause programs to unexpectedly crash.
You guys talk big about how in java unhandled exceptions are not possible but that is BS because I see plenty of crashed Java apps with a message about unhandled exceptions, usually something about a nil pointer. In other languages, unhandled exceptions seem to be always possible.
Crashing unexpectedly on error, destroying the user's work, is NOT acceptable.
User types a 'b' in a number box and the program throws an exception, crashing because b is not a recognized digit. This is BS and yet is in a standard library - throwing an exception on nonnumerical digits n a number parse. This should be either a transparent recoverable error or a notified recoverable error. Exceptions should not be involved.
Out of Memory? Are you people retarded? When that happens you crash? Are you stupid or what? You want to take a guess what you are supposed to do when memory is about to run out? Here's a hint -- if you are using the stock malloc or new that comes with your library, you are the world's greatest fool.
Dennis Atkins
Wednesday, October 15, 2003
Ok I'll bite.
I want to hear what you do on out of memory.
Or my favorite stack failure...
http://www.summitsage.com/
christopher baus (tahoe, nv)
Wednesday, October 15, 2003
I'd rather have my program crash than continue on with bad data.
At least if it crashes I know something has gone wrong. If it silent continues, are you going to come and recover my data when in a months time I find it's all gone bad because you failed to check a single return code?
No thanks, I'll take the crash any day of the week.
Sum Dum Gai
Wednesday, October 15, 2003
Some people posting about exceptions are either trolling or entirely ignorant of exception handling.
So some Java standard library function throws an exception when it tries to convert a non-numeric string to an integer? And that's bad because it could cause the whole program to crash?
The exception doesn't cause the crash. The programmer who didn't expect or handle the exception caused the crash. If the programmer had ignored a result code and caused a divide-by-zero or stored junk in a database 2,000 function calls later, is that better?
Exceptions don't kill programs. Programmers who don't handle errors kill programs.
I agree that a string to integer conversion function that chokes on non-numeric characters is a little brain-dead, but that kind of design seems to fit the Java gestalt. In the C standard library the conversion stops at the first non-numeric character, and no error is returned. Different languages, different philosophies. None of this has anything to do with exceptions.
You don't want your program to crash when someone types 'b' into a text box? Check your inputs instead of calling everyone else retarded. Or catch the exception and deal with it--that's what they're for. It's really easy and you won't crash your program:
try:
i = convertToInt(s)
catch NotNumericException:
// tell the user about the bad input
// or, set i to 0
// or, remove the non-digits from the string and try again
// or, throw a BadInputTryAgain exception
// YOU are in control, dummy
...
See how easy that is?
Anyone who posts that exceptions cause unpredicatable control flow, or cause programs to crash when they wouldn't otherwise crash, doesn't know what they're talking about. Exceptions are not the answer to everything, and they don't make bad code better, but at least come up with real arguments and not half-baked FUD.
Gregory Jorgensen
Wednesday, October 15, 2003
Chris,
You keep an eye on the memory situation very regularly, such as in your main event loop, or in a sentinal thread as appropriate, so if memory is getting low you notify the user. If memory does fail inside your own personal malloc, new, or other memory allocation point of entry, you release your 2ndary buffer, reallocate, and continue, setting a flag so that the user will be notified to save work and close windows. If memory fails again, you release your final buffer which is designed to have enough room to recover from any situtation and you autosave all work and the state to temp files. Also, all large allocations should be able to back out of in general and free up the memory they have so far allocated. The main place you go haywire is when you get a request to create a large object/document/etc, or if you get hit with a huge number of requests to create/open objects/documents/etc. So you make sure this code is able to back out from any stage.
Dennis Atkins
Wednesday, October 15, 2003
Greg,
If I'm parsing the entire number myself to check for errors, I have to ask why I am bothering to follow that up with a library routine to parse it afterwards. Seems pretty stupid.
Dennis Atkins
Wednesday, October 15, 2003
My programs don't crash when exceptions occur since I avoid libraries with exceptions and when I have to use them, I wrap them and convert to error codes as joel does. I have approved of the use of exceptions very occasionally in actual *assertion failure* situations where there is no possible way to recover and a trace is helpful. But I get a stack trace anyway because that is what you get if you are running either a debugger or a modern OS, which you should be doing anyway. You guys do realize that you don't need to trigger an exception to get a stack trace during a crash? Your debugger (not the one in your IDE -- the other one) will trap your crashes and back trace the stack to show exactly where the failure occured.
My complaints about programs crashing are of an empirical nature -- I am seeing way too much crappy software failing on unhandled exceptions. This is the reality. Talk about how it's done by bad programmers, probably so in some cases. Their decision to compile with exceptions enabled proves they were not so bright. But some of the blame can be placed on the unjustified fanatical devotion and hype surrounding exceptions being the perfect solution to error handling, which is entirely false.
Dennis Atkins
Wednesday, October 15, 2003
Dennis,
So you have a complicated strategy for handling out of memory situations. I've never actually experienced an out of memory situation; and I develop for smart phones! A *far* more common problem is running out of disk space. It's happened to me plunty of times on my desktop -- neither apps nor the operation system seem to handle that condition very well. How do you handle that far more common case?
"You guys do realize that you don't need to trigger an exception to get a stack trace during a crash?"
A crash is an exception!! (just one trapped by the OS or debugger).
I'm not sure where you're finding all this crashing java applications. I've almost never seen an app fail with an exception trace. Pretty much once I week a get one of those friendly "the application has failed" dialog boxes in Windows.
Anyways, I'm still not sure why you think status codes are better? Ignoring an error is far worse than having an app terminate. Do you not agree?
Almost Anonymous
Thursday, October 16, 2003
Dennis wrote:
"If I'm parsing the entire number myself to check for errors, I have to ask why I am bothering to follow that up with a library routine to parse it afterwards. Seems pretty stupid."
Agreed, it does seem stupid. But it has nothing to do with exceptions.
If you check the string for non-digits before passing it to the library function, you know the library function won't throw that kind of exception, BUT you still have to handle the bad input. And there are other problems you may have to deal with, such as overflows.
If bad input is possible but not common, you can use the library function and catch the exceptions if they happen. Then you still have to figure out what to do.
The two situations are logically equivalent, but the exception handling version is easier to write because you don't have to duplicate the standard library code.
The only alternative is to write your own library functions that don't throw exceptions and work exactly as you think they should work. That's fine, too, but it doesn't demonstrate that exceptions are good or bad, only that you don't like using them.
Gregory Jorgensen
Thursday, October 16, 2003
OK Greg,
But you realize that you are advocating using exceptions to check user input, which is a pretty bad way to structure checking user input in my opinion since malformed user input is not really an exceptional circumstance. My opinion is that this is certainly a misuse of exceptions, and this sort of use, and it's endemic use in libraries of non-exceptional circumstances throwing exceptions, seems a poor design choice.
Dennis Atkins
Thursday, October 16, 2003
Almost,
I don't agree because it depends on the situation. Errors should not be ignored. But given a choice between ignoring and crashing, it depends. Stack-heap collision? Crash before damage occurs rather than keep running with a bad stack. Bad digit typed? Ignoring is better than crashing in most circumstances, unless the number was seconds to countdown before launching the nukes.
Dennis Atkins
Thursday, October 16, 2003
Almost,
Regarding the disk thing, I've never seen it on any computer I have, but I handle the document case by putting up a "The file 'filename' could not be saved because the disk 'volume name' is full." [OK]
This at least gives them the option of saving to another volume!
In critical cases with files you are autosaving, you could delete any temp files available, or even go wild and create a ram disk.
In other cases, you can try other strategies. What do you do? Crashing doesn't seem a good answer.
And how come you run out of disk space anyway? That's one of the things most OSs make pretty clear how much you have left of.
Dennis Atkins
Thursday, October 16, 2003
Dennis wrote:
"But you realize that you are advocating using exceptions to check user input, which is a pretty bad way to structure checking user input in my opinion since malformed user input is not really an exceptional circumstance. My opinion is that this is certainly a misuse of exceptions, and this sort of use, and it's endemic use in libraries of non-exceptional circumstances throwing exceptions, seems a poor design choice."
No, I was simply responding to your original complaint about a library function (in Java?) that throws an exception when it encounters a non-digit. I agreed that it's not a great design, but I don't think throwing an exception is the end of the world, either. The function can either do nothing silently (as a C library function would do) or raise a fuss (as Java library functions do).
A conversion function that didn't throw an exception would still have to deal with the possibility of bad inputs. What alternatives do you suggest? Ignoring all non-digits? Stopping at the first non-digit? Returning an error code? Returning 0? Do you see how throwing an exception lets YOU--the user of the library function--decide what to do?
Don't extrapolate from trivial examples to assume what I may or may not do in a real program. A better UI for an input field that expects numbers is to have an input control that only accepts digits. Don't allow the bad input in the first place. I alway prefer not allowing the bad inputs over giving error messages. In some applications (HTML forms come to mind) this isn't possible, so you are stuck with writing your own conversion or using whatever the language libraries provide.
If the only downside to the library function is that it throws exceptions, and I'd have to do exactly the same work as the library function just to avoid using exceptions, I'd call that a bad tradeoff of my time: I'll just catch the exception rather than rewrite the library function. But that's me.
Gregory Jorgensen
Thursday, October 16, 2003
> Are you people retarded? When that happens you crash? Are you stupid or what?
Spewing abuse is not argument.
You think Joel's so infallible, well, go blow him, 'kay?
Portabella
Thursday, October 16, 2003
Dennis,
You seem to think that the ParseInt function isn't important enough to have an exception; and I'm not sure that's right.
Greg has a point, what do you do in case of bad input? If I'm validating input just before the data gets inserted into a database or saved to a file I sure as heck don't want invalidate data being saved. I can't really think of any case were I'd be validating user input and want to bad input to persist. Exception use in this case is definitely to err on the side of caution -- you might thing it's a little too cautious (and I would agree) but I don't consider it all that bad of a thing.
"In critical cases with files you are autosaving, you could delete any temp files available, or even go wild and create a ram disk."
Most file-based applications behave correctly but some applications use the disk more implicitly and they just assume they have disk space. Windows XP is a little better than previous Windows versions about handling this case gracefully. But it's still not good.
"And how come you run out of disk space anyway? That's one of the things most OSs make pretty clear how much you have left of."
Sometimes I get down to a few hundred megabytes free and then it doesn't take much (especially with broadband) to fill that up accidentally. I usually don't notice until things start to go bad.
Almost Anonymous
Thursday, October 16, 2003
Choosing to crashing when recovery is possible instead is a stupid, retarded design that comes out of laziness towards real error handling, ignorance, or maybe incompetance. Thus this is not abuse but simple facts. If you don't document any of your code, you are also ignorant or incompetant. No abuse, just facts. If you never check for errors when opening files, you are also ignorant or incompetant. It's not abuse to state the facts. If you go to see a doctor because you have pneumonia and he says you need leeches, he is ignorant or incompetant. If your accountant tells you don't bother paying taxes because the IRS is too busy to deal with a little guy like you, your accountant is ignorant or incompetant. Saying so is not abusive, it's pointing out obvious facts.
One of the most common examples of supposedly unrecoverable situations that exceptions deal with is out of memory. This is persented as an unreceverable situation that can not be handled and thus, rather than even present an error message, or try to save unsaved work to temporary recovery files, the 'elegant' solution is said by exception proponents is to suddenly and unexpectedly crash the program.
Crashing when malloc fails is sophomore stuff. If you are creating commercial software that crashes the first time memory runs out, you don't know what you are doing. Time to move out of high school and start writing software that works rather than hacking together half-baked software that crashes, taking the user's work with it for dumb reasons.
And Portapotty, your comment was uncalled for. Joel's right on this one and you're wrong. Making those sort of homophobic slurs are *way* out of line.
Dennis Atkins
Thursday, October 16, 2003
OK, almost. I see what you're saying on disk space. I've seen out of memory more often than disk space over the years so I guess we have different experiences. Probably since I've tended to back up or get another disk before disk space gets too low and keep at least 1/4 of each disk free, so it's just a personal preference thing that's led each of us to see different failure frequencies.
Well, if a program really does run out of disk space and there's just isn't any more, I do think the user should be notified since it's something only they can rectify. I don't think that sort of error condition should be ignored, whether one is using exceptions or error codes.
Dennis Atkins
Thursday, October 16, 2003
Memory doesn't run out... it just gets paged to disk!
Well I'm very shortly going to be purchasing a 120GB drive (along with the computer to go with it). That should keep disk spaces issues at bay for a week or so. ;)
Almost Anonymous
Thursday, October 16, 2003
> your comment was uncalled for
But your comments ("stupid, retarded")... are perfectly OK?
Get real: you haven't presented a shred of evidence for your views, you insult and ignore anyone that contradicts you, and the ugly and hostile way you're presenting what you think is making you *deservedly* look like an asshole.
Portabella
Thursday, October 16, 2003
When developing for Smartphones and out of memory condition is fairly likely. I do not handle out of memory exceptions, they unravel the stack all the way back to the OS which displays the appropriate message.
Surprisingly, this is actually a graceful shutdown of the application. The destructors on all my objects are called as the stack unwinds, closing and saving open files and retaining any configuration settings. It also unregisters any handlers, closes on-screen widgets, and so on.
I didn't have to code for any of that -- it comes for free by having a properly designed C++ application and using exceptions.
That's the ultimate power of exceptions.
As for having to deal with exceptions in seemly unimportant situations (like parsing numbers) I say that there aren't any unimportant situations. If something can't be handled by a called function then it's an exception and should be dealt with.
Almost Anonymous
Thursday, October 16, 2003
The most problematic aspects I see about exceptions are:
1. No coherent strategy for using them. For example -
programmers are sometimes encoureged to use
return codes (for non-exceptional circumstances) and
sometimes to use exceptions (for exceptional cases).
If you look at it closely you see that if you follow this
pattern (encoureged by .NET documentation) than you
actually have TWO error returning mechanisms instead
of just one (return codes ...).
In all my 9+ years of experience in the field I've never
seen a coherent strategy of using exceptions (C++, Java
and even C#) applied in real-world projects.
That's not to say that return codes are much better in
this regard ... At least here we are not pretending so :-)
2. NOT Mission critical:
Assume that you are on a plane with an auto-pilot
software.
Would you prefer that the program throws an
unhandled exception in case of an error or fail to
handle an erroneous return code ?
The first case is obvious: the plane will crash due to
deterministic software termination (enforced by the
exceptions mechanism).
The second case is not so obvious: The plane may
crash, but at least you have a chance since failing
to account for the erroneous return code may still
not cause the program to crash.
Traditionally I was using C ASSERT macros to check for
invariants in the DEBUG code. But before shipping a RELEASE code I always turned off these C ASSERTs so that my software wouldn't crash EVEN in case an invariant was
violated - instead I added a hefty amount of logging that
allowed me to find such problems quickly.
<note>I know this is not always the good thing to do
but many times it is just right</note>
With exceptions this option will not work as exceptions
will ALWAYS terminate my application (there goes "MISSION
CRITICAL").
Another point to consider: As was noted in some earlier
thread - there isn't much accumulated data as to the
productiveness/effectiveness of using exceptions vs.
using return codes.
My experience matches that of Dennis Atkins that most Java applications tend to be less robust than applications written using a non-exception error handling mechanism (say - VB). You see many applications (even commercial
ones - like PVCS VM ..) display these dreaded "java.lang.NullPointerException" message boxes.
This is not something I recall from earlier environments.
Even when C++ was the dominant language - only few companies dared using its exceptions mechanism. Most
settled for return codes.
Also note that most of the infra-structure in existance
today (WIN32 API, COM, OLE etc.) use return codes.
Putting exceptions into the CLR (.NET) is a very risky move
(IMHO) - one that may result in making the entire Windows
platform a less robust one, but these are just speculations ...
Liron Levy
Thursday, October 16, 2003
> You see many applications (even commercial
ones - like PVCS VM ..) display these dreaded "java.lang.NullPointerException" message boxes.
This is not something I recall from earlier environments.
But is the difference *more errors* or *more error reporting*? That's really the question, and I think the two are being conflated, especially by Mr. Atkins.
I agree that it's terrifically bogus to shove a stack trace in the user's face, from a usability point of view. But not all Java apps do. For example, LimeWire just puts up a dialog that tells you that an error has occured; you can hunt down the log file if you care about which error it was. Similarly, plenty of Java Web applications just put up an error page; this is very easy to do too.
The default error reporting tends to be the stack trace, because it's most useful for developers. *Serious developers change the default*.
Portabella
Thursday, October 16, 2003
"No coherent strategy for using them. For example - programmers are sometimes encoureged to use return codes (for non-exceptional circumstances) and sometimes to use exceptions (for exceptional cases)."
I work in an environment that uses both exceptions and return codes. Surprisingly it isn't much of an issue. I definately don't mind using status codes rather than exceptions so it really doesn't seem that odd to me. The environment also has a method that turns the status code into an exception if it isn't OK.
Even status codes isn't exactly coherient, either. Some functions return bools (true on success, false on failure) others return an Int (0 on success, anything else on failure) others mix the result with the error (negative value is error, positive is result of function).
"The first case is obvious: the plane will crash due to
deterministic software termination (enforced by the
exceptions mechanism)."
Not necessary. In worst case, the top-level exception handler will be triggered that will setup a somewhat graceful shutdown. This at least will turn off the autopilot and alert the pilot of the problem. Maybe even better the software will just reboot and be back up in running.
"The second case is not so obvious: The plane may
crash, but at least you have a chance since failing
to account for the erroneous return code may still
not cause the program to crash."
In this case, the pilot has no idea there is a problem. There might have been a mathematically overflow and now the altude reading is all wrong. The pilot thinking everything is ok then drives the plane into the ground.
The error you know about is always better than the error you don't.
Almost Anonymous
Thursday, October 16, 2003
Oops... wish I could edit posts! That should be "mathematical" and "altitude"...
Almost Anonymous
Thursday, October 16, 2003
 Recent Topics
Fog Creek Home
| 
