- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Can you make any nice-sounding arguments against it? or maybe you can just repeat: "Anything that I don't like, by definition, sucks." and the go back to writing php "programs".
Admin
Maybe you don't understand vernacular. In reality = real world development not theoritical BS. Pain in the ass = lots of tedious work. Little or no payback = little or no benefit. In general, when evaluating whether X is good you ask what does X require and what does X yield.
I submit that for most development projects, the Java exception model is a net negative. By that, I don't mean that you should just silently catch all exceptions. I am saying that the requirement that you catch or declare all exception types at the method level is a big waste of time. You should be focusing on what happens 99% that you can do something about. The java model either forces me to do stupid things like Joost_ points out or forces me to spend a disproportionate amount of time coding for the unlikely. I am not just speculating here. I have worked on real-world corporate enterprise level systems written in Java.
The exception approach I prefer is to have a standard top level cath-all exception handler that logs/e-mails/pages and halts the process/application. As you move through the life cycle of the project, you see what exception scenarios occur in the real-world. You then add specific/special case handlers as needed. That's safe. There's nothing safer about making me declare those exception types all they way up the call stack.
Admin
Yes, with substance and without ad hominem attacks, too.
Admin
Why don't you post some java code that takes a file name from the user and attempts to open it. My point will make itself.
Admin
(ignoring the "fanboy" troll that started all of this...)
Fair enough, substative arguments only from now on...
First problem, there is no such requirment to catch or declare ALL exception types. It is perfectly legal to handle the base type "Exception" or "RuntimeException" or both. That should just about handle any exception type I can think of.
I would submit that any programming language requires you to "spend a disproportionate amount of time coding for the unlikely" It is usually refered to as the 80-20 rule. Having worked on corporate enterprise level systems in both java and other languages, I have indeed seen this to be the case.
Add exception handlers as needed? Is it not better practice to anticipate possible/plausible exceptions and handle them from the get go? Even so, this is still possible in java without " declare those exception types all they way up the call stack." Just create an class with static methods to log/email/page and call that in the catch block ... something like this would be functionaly equivilant to your preference:
try{
.. do some corporate enterprise level processing
}catch (Exception ex){
JohnOsCustomErrorHandlerClass.notifyeveryoneandlogtheproblem(ex);
System.exit();
}
This is safe to, but I think that maybe pushing the exception up the stack trace might be just a better option, and not too much a pain in the ass.
Admin
So what's the point? How is this beneficial?
No, I dont' think it is. Do you really do this? If so, how many times has what you came up with before testing and deployement to real-world conditions been useful?
My whole point is that I can put one catch in at the very top in other languages. I don't need to create a static method and I don't have to waste time putting a try catch in every method with a call to this static method or explicitly declaring that I can throw an exception. I can just put try catches in where I know that I can really do something useful at local level.
Admin
In general, yes I do this. I understand your point that it doesn't always match what happens in the "real-world", however, my subjective opinion is that this way, fewer issues have to get reworked at testing time. In fact, I think its important to al least consider some of the "What ifs...". Do you really not do this?
I think that I understand you clearly now. Let me paraphrase: You think mandatory nature of java's exception policies/practices are a pain in the ass because you *have* to declare at the top of every method that it might throw an exception, as opposed to just adding one exception catch block at the top of the stack, like you can do with other languages and exceptions are automagically passed up the stack?
If that is correct, then my point is this: Your preference for not explicitly declaring exceptions doesn't make the Java policy a failed experiment. In fact, I find the clarity that comes with knowing which methods might throw an exception generally useful.
I think we agree on this point. I was just pointing out that there were alternative ways to accomplish your stated preference.
Admin
I love how you respond with rhetorical symetry when in fact what you asked me is not a question regarding exceptions but if I consider what-ifs. Why, yes, I do. But not in the context of exceptions.
Admin
I have to tell you that I have gotten more than my fair share of entertainment out of this thread.
Maybe we can call a truce on this. Here is my proposal:
JohnO and TankerJoe agree that:
agreed? cease fire? the WTF peace accords?
Admin
Indeed it does. AND THAT IS A GOOD THING! Very unlikely corner cases that were overlooked during testing and then take down a production server during the weekend are something you want to avoid at nearly any cost.
Admin
It's exactly the high-level catch-all you want.
Hard to say, because a properly handled exception rarely evokes much attention. Like most quality-improvement stuff, it only gets noticed when it's NOT done and something fails because of it.
But it's one of the oldest wisdoms of software engineering that the cost of fixing an error (which a not-properly-handled exception very often is) grows very disproportionally in the later stages of the development process. An error found in production can easily cost 100 times as much to fix as one found during developer testing, let alone one that doesn't occur because the compiler forced you to handle an exception.
You dismiss this argument as "theoretical BS", but it's one grown from long, painful experience. Or maybe it's the claim that checked exceptions have a significant contribution to reducing late-found errors that you're dismissing. The problem is that this is very hard to prove OR disprove, and neither of us can really offer hard evidence.
I can only say that I have seen a number of nasty problems caused by unhandled RuntimeExceptions, and it seems rather logical to me that if all exceptions were unchecked like REs are, this would occur more often.
The other question is how much additional work the checked exception concept causes. You say it's a "pain in the ass", I say it's a minor annoyance. I absolutely don't feel that I'm spending a significant amount of time on it.
Admin
Very rought outline (I certainly won't be bothered to look up all the API details to prove a point):
Data result;
try {
String fileName = showFileDialog("Please choose file");
Reader reader = new InputStreamReader(new FileInputStream(fileName));
result = parseFile(reader);
}
catch (Exception e)
{
showErrorDialog("There was a problem reading the file you chose:\n"+e.toString());
result = DEFAULT_DATA;
}
return result;
Note that the single catch block handles all kinds of IO exceptions as well as custom exceptions e.g. when the file is malformed, if you have a good toString() method on those. You could do separate catch blocks if you need to react differently.
Now I can't really say I see your point in there. Maybe if you provide code in some other language that you consider to have a superior exception concept?
Admin
What's funny is you did the same thing as Jack -- you bring up something different and then pretend that's what I am arguing against. I know full well that it is cheaper to fix bugs as early in the software development cycle as possible and I challenge you to find where I ever contradicted that. Yet you pretend that I called that theoretical BS. I did no such thing.
What I am calling theoretical BS is that java's requirement that I catch or declare exceptions at the method level improves my program or the development process in any way.
Admin
My point is simple. In the code above, I certainly expect that the file will not exist sometimes, yet I must handle that as an "exception."
Further, catching all exceptions as you have done is horrible. If you didnt' have to declare them all to get your code to compile, you probably wouldn't have done that.
I don't know if you have done any serious development in a language other than Java, but I spent a lot of time in Java, moved on, and found that the exception model really was counterproductive to getting average developers in the real-world to write good code that didn't hide exceptions like your code does.
I don't want all exceptions swallowed deep inside methods just so the compiler won't complain. But that's what java encourages, IMO.
Admin
I think the Java "catch or specify" requirement is a good idea in most cases. Not necessarily because there is a risk of developers forgetting to handle exceptions without the Java compiler holding their hands. But because it forces source level documentation of the exceptions a method can throw (at least for checked exceptions). A good IDE can pick up on this information and easily do most of the grunt work for you (by generating try/catch blocks for example). So with the help of an IDE, how much of a pain-in-the-ass are checked exceptions really?
The only time when I've found that checked exceptions got in the way was when dealing directly with JDBC. A lot of times the only reasonable thing that can be done about an exception is log/email/error screen. I believe in this case its appropriate to have a top level catch-all. Now, JDBC is usually at the "bottom layer" of the application, while the code that handles the interface is at the "top layer". Should every method in-between the top and the bottom have to declare "throws SQLException"? That would be madness. In such cases I usually find myself catching SQLException at the bottom and then wrapping it in a custom RuntimeException and then rethrowing that, so that it can be handled in the catch-all without turning all the code in-between into an ugly mess.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
Admin
And he're you're doing the same thing you're accusing me of doing while accusing you of doing it. What I said what that I was not completely sure WHAT you were calling "theoretical BS", the suggested, as second alternative that you might mean the claim "that checked exceptions have a significant contribution to reducing late-found errors", which is exactly what you're now saying you DID mean. The rest of my posting concerned that argument, and you handily ignored it.
Admin
For choosing a file you would use a dialog that shows actual files in the file system to pick from - I certainly DON'T expect the chosen file not to exist.
Are you arguing that no circumstance that could possibly be foreseen at all should ever produce an exception? That would basically mean the abolishment of the exception concept. Is that your point? How would you design this specific API?
No. I haven't done it because I'm too lazy to write fully-fleshed-out, detailed code just to answer a challenge by someone who's too lazy himself to back up his arguments in the same way.
It would be nicer, and perfectly sufficient to have two catch blocks, one for IOException, one for ParseException. Those should be all that's needed. I don't actually think catching "Exception" is all that horrible.
Again: if you think it's so horrible, let's see YOUR code that's so much better, in whatever language you prefer.
True, that's sometimes what happens But IMO in nearly all cases, the higher-level exception handling code can't actually do much with the exceptions it catches either, other than very general logging and maybe showing an error dialog. So how are "swallowed" exceptions so bad? Alternatively, you can rethrow them wrapped in a more general exception. Yes, it causes some duplicated boilerplate code. I'm not saying the concept is without flaws, just that it's a rarer and smaller problem than you make it seem, while the advantages are bigger than you say.
Admin
Because the program blindly continues to run as if nothing "exceptional" has happened all because someone was trying to shut the compiler up. This is my key point. I don't want my program to continue running after an exception has occured unless someone has specifically written a catch for that scenario.
Theoretically (here's where my theoretical BS statement was meant to go), someone will carefully analyze every exception that could possibly be caught by their code and write a carefully crafted and well-tested catch block that does exactly the right thing for every exception type. That assumes that whoever wrote the exception throwing code carefully analyzed when they threw exceptions and of what type.
It's almost impossible to test exception handling code in a realistic fashion. I am a smart guy with years of exerience and I never cease to be amazed at what kind of wierd confluence of failures and exceptions actually occur in complex production systems.
So I guess my point, in a nutshell, is that I don't like the java exception model because it encourages people to inappropriately catch exceptions they don't really handle and/or to just declare that their method can throw Exception, which negates the whole java exception concept anyway.
Well, as you said several posts up, that's just an opinion and I disagree.
Admin
"...especially those who's number negation..."
You have angered the apostrophe Nazis.
Admin
The Java vs C# exception debates are missing the production end user perspective.
Any default stack trace exception reporting language is fundamentally problematic for the end user. We're talking about people who have enough difficulty in learning to read a simple error message:
Cannot open file reprot.doc: File not found.
With time and patience, this user may be able to be trained to read that error, and realize they twiddled the 'r' and the 'o'.
However, if you give that user a stack trace, no training in the world is likely to get them to be able to read it. Worse, they're possibly going to be less likely to bother looking at error messages in the future.
Most stack traces are huge, and they tell the typical user nothing.
Sure, they're invaluable for developers. However, the further the application gets from the developers' hands, the less valuable they become. By the time the product ends up in the hands of a user, they're a negative: at best, they tell the user that the developer wasn't clever enough to realize that the exception would happen (depending on the situation, the word 'eventually' may be in order here.)
As such, Java, C#, and Python all lose big time here.
I am not aware of how C++ handles these situations. I know I have not been subjected to C++ stack traces due to minor environmental discrepancies - but for all I know, that's just because most C++ programmers know their stuff. Or it could be that C++ doesn't have any default exceptions, and so only those programmers who actually want to deal with them are subjected to them.