Proper exception handling

[constv]

Discredited by whom? By you - sorry, you do not have enough authority to discredit this idea.

This is lame... Not by me, by the software community in general. And you know it well. Spring, Hibernate, all languages other than Java, and, finally Sun's very own EJB 3.x spec. No checked exceptions. For a good reason: it's just better and easier that way.

rovide some proof, please.

Although I don't owe you any proof, the people who work with me and who have worked with me on projects throughout the years read these forums daily and could easily catch me if I were lying. Also, like most people in these forums, I usually post either to ask a question or to help others with practical solutions for the problems they are trying to tackle. And may I say so, I think I have been able to provide some real working answers to quite a few questions, and people have thanked me for that more than once. Unlike you, I do not post for the sake of arguing to death, just to pick on a sentence and argue it senselessly. I have been using Java for many years, I had used checked exceptions before, and always looked for a better, cleaner, and more reliable way to do things. I never blindly follow a dogma. I think for myself. Also, I have never seen a real-life Java project with checked exceptions where error handling wasn't a mess to one degree or another. (Don't even think about saying that I haven't seen anything: I do consulting for a living and I have seen lots of projects!) On the other hand, I have seen, and have myself implemented many projects that used RTEs only where error handling was indeed clean, simple, and bullet-proof. In fact, just recently a team lead of one of my clients thanked me for introducing a very coherent, simple and reliable error handling mechanism on their project.

They do not introduce safety, but they may help to write safer code if are properly used.

Unfortunately, it is a utopian statement, wishful thinking. The problem with checked exceptions is exactly the fact that in practice it has turned out that it is not easy to use them properly. They get in the way more often than they may be helpful. And when they get in the way, people are most likely to misuse them.

It would be better to say "may be misused".

Whatever...as long as "may be" means in more than 90% of all cases.

But there are a lot of other techniques subjected to heavy misuse.

True. Not all techniques however are designed to encourage misuse, like checked exceptions.

I have seen such code, but it has not survive long in any of the projects that
I have participated.

Good for you. It survives almost everywhere else and results in completely incoherent error handling where cryptic errors show up in production, and people spend weeks and months trying to trace the causes. Examples from my experience: a huge financial institution in Boston, one of the world's largest life insurance companies, a large data archiving company, etc. These are just a few of the projects where the problem was raised to the level of the top priority to fix. They had special projects allocated to implement what they would originally call "a better exception handling framework".

but I do not see what you blame here - if module can and should do something about exception, that it should - and in this case iut does not matter is exception checked or not,

Finally, you said something that makes complete sense. I don't blame anything here. In fact, this is EXACTLY my point. Once I know that the given module must do something about an exceptional condition - I don't need the compiler to enforce it on me. If I don't need to do anything here, I should not interrupt any possible exceptions traveling through this module to the designated handler. Using your road signs analogy, it is the responsibility of the driver to make the correct turn, not the road sign to force the car to turn. An exception is out there to rewind the call stack and send a signal to whomever is interested to act upon it, not to force every single method in the call stack - especially the immediate caller - to implement a bunch of junk code just to pass it through or swallow when it has no idea what to do with that error.

You essentially say "I do so, it is the only valid way to do, it should always done so".

I say "in most cases it is better to do so, but most cases are not all cases, there are cases when other approaches are preferable, so stop, think, think, once more think and then make your own decision deliberately" .

This is a lie, it is not what I say. I have admitted that I had used checked exceptions before myself, and I tried both approaches. It is because I have actually done a lot of thinking that I have concluded that the RTE approach is better. I am not the only one. Apparently, the authors of Spring and Hibernate have come to the same conclusions. Apparently, folks at Sun are leaning towards this as well. I was answering someone's question as to what the better approach was, and I had shared my findings. I have also offered some folks - in various threads - real working practical solutions that I was thanked for. You on the other hand prefer a pointless demagogy for the sake of arguing.

I know you will need to have the last word, you always do. So go ahead, knock yourself out. I have better things to do than to argue with you so don't expect any more replies.

[al0]

This is lame... Not by me, by the software community in general.

References, please. As was discussed earlier, your your references were to your opinion. Other references in this thread were to articles that recognizes usability of checked exceptions for specific purposes.

And you know it well. Spring, Hibernate,

Sure general purpose frameworks should use unchecked exceptions, as checked may be useful for business (so-called contingency) situations only.

all languages other than Java,

Not exactly, checked exception per se are unique for Java, but some other languages provide while not exactly the same but similar concepts. Take a look at "Exception handling" on wikipedia.

and, finally Sun's very own EJB 3.x spec. No checked exceptions. For a good reason: it's just better and easier that way.

And that's absolutely proper solution - checked exceptions are not appropriate for infrastructure.

Also, like most people in these forums, I usually post either to ask a question or to help others with practical solutions for the problems they are trying to tackle.

I as well - and by order of magnitude more then you. You have 138 posts, I - over 1400 and vast majority of them (up to 85-90 percents) are answers and explanations (I held such kind of flame-war like discussions with you only).
And I have asked not a proof of your competency (it is more then clear from your posts that you are competent enough, way above average), but proof that you vision in this specific question are shared by many.

Also, I have never seen a real-life Java project with checked exceptions where error handling wasn't a mess to one degree or another.

You are just unlucky - I have seen such projects. projects in which most of the exceptions were unchecked, but few carefully selected were checked. It is not something unattainable or utopic.

In fact, just recently a team lead of one of my clients thanked me for introducing a very coherent, simple and reliable error handling mechanism on their project.

I never have said that RTE is evil, and I have said then if only one kind of exceptions should be available, it should be RTE. So it does not surprise me that it is possible to make a good and clean project with RTE only.
BTW, I guess that I understand where lie a difference in our experience - as far as I may conclude from your posts you are a kind of consulter called to rescue projects that start to go south. So you mostly see junk (unless you look on your own code).

I mostly do in-house development. And have enough authority and influence to make sure that project is developed properly from start.

Unfortunately, it is a utopian statement, wishful thinking.

Why - my statement was on promise "if used properly".

The problem with checked exceptions is exactly the fact that in practice it has turned out that it is not easy to use them properly.

Yes, not so easy, but not impossibly hard. The main prejudice against checked exceptions was caused by heavy misuse of them in JDK libraries.
But it does not mean that they are evis per se.

They get in the way more often than they may be helpful. And when they get in the way, people are most likely to misuse them.

Sorry, but your logic is flawed at this point - not "when they get in the way, they would be misused", but "when they are misused, they would get in the way".

True. Not all techniques however are designed to encourage misuse, like checked exceptions.

I would formulate that somewhat different - "their misuse by design encourage their misuse by implementation". So (and I have said it already) you should be very, very careful with checked exceptions by design.

Examples from my experience: a huge financial institution in Boston, one of the world's largest life insurance companies, a large data archiving company, etc.

The bigger the company, the more chaotic it is (in software development, anyway) Disclaimer - there are exceptions from this rule.

Once I know that the given module must do something about an exceptional condition - I don't need the compiler to enforce it on me.

You may forget, I may forget, anybody else may forget. We are humans, not superhumans. Would you like to have untyped variables?

If I don't need to do anything here, I should not interrupt any possible exceptions traveling through this module to the designated handler.

And you need not - in most IDEs you even need not travel to the class header to add exception declaration, just press a relevant key combination and continue your .work.

not to force every single method in the call stack - especially the immediate caller - to implement a bunch of junk code just to pass it through or swallow when it has no idea what to do with that error.

I do not understand when you see "bunch of junk code" - if you wish not handle exception in this method, just add it to the method signature. Is it "bunch of junk code"? Definitely, no.

Apparently, the authors of Spring and Hibernate have come to the same conclusions. Apparently, folks at Sun are leaning towards this as well.

For framework-like code, yes, yes, and once more yes. 100%+ agree.

I was answering someone's question as to what the better approach was, and I had shared my findings. I have also offered some folks - in various threads - real working practical solutions that I was thanked for. You on the other hand prefer a pointless demagogy for the sake of arguing.

I did not try to challenge the fact that your position comes from your experience and (likely a lot of) thinking. My point was somewhat different:
You say to others "I have thought it out and decided that this is proper way, so follow it and only it".
I say to others "I thought it over and found this and that pro and contra, weighed them and made my opinion. But weigh them, think about them and make your and only your decision".

Concerning rendered help and thanks I have answered at the top of this message Concerning discussions - with you only.

[constv]

Olexandr,
just to make things clear, I did not intend this thread to burst in flames. I respect your opinion, and, it seems that - after all is said - we don't differ significantly in our opinions. You state that checked exceptions have the right to exist and may be of value in certain - however marginal - situations. And I don't reject this point. You and I both agree that it is not appropriate to use checked exceptions in certain cases, such as frameworks, and general-purpose solutions that should not make assumptions regarding the [perhaps, yet unknown] modules and systems that would be using them. We differ, it seems, in the outlook on what is more practical, and whether the existence of checked exceptions in the system for the benefit of marginal cases is justified.

From the practical stand-point, I strongly believe (and I do not insist that you believe this too) that the way checked exceptions were introduced and hyped up in Java was very irresponsible, and resulted in a disaster. 1) As you have said, the JDK itself has not been using them properly, and the Exception class didn't even have exception nesting until JDK 1.4! They didn't even think that re-throwing with a nested cause was necessary!! 2) Something that is only good for marginal and non-general-purpose solutions was introduced as the ultimate solution to error handling with the implication that most custom exceptions must be checked. That's how most people interpreted it. That resulted in developers using mostly checked exceptions. Look at the code examples in books and on the Internet. The vast majority of them use exception handling that doesn't make sense.

So, although, yes, I agree with you, checked exceptions may be used properly and with benefits in certain cases, where my point differs significantly from yours is that I believe that the checked exceptions implementation in Java has done more harm than good. For so many programmers, error handling has become an afterthought, a knee-jerk reaction to a compiler alert, not part of the design. You, and some other competent programmers, may apply careful design and analysis to error handling, but so many - too many - do not. And I see it every day, unfortunately. Again, you don't have to agree. But I know that more and more people in the Java community are coming to similar conclusions every day. We finally see books coming out that say: use unchecked exceptions, the debate is over.

In the past few years I have become very passionate about the issue because I see that improper error handling is one of the major/top contributors to messy chaotic, unmaintainable software projects. So many people are mis-using this particular feature of the Java language that it inevitably makes me think: perhaps, we are better off without it all together? (The C# architects decided that a long time ago - after much deliberations.) Especially because there is an alternative more robust and more intuitive solution that implies thinking first. RTEs also may be misused, for sure. But I have discovered that it is easier to identify and correct such problems quickly than chasing mishandled checked exceptions. Far easier and quicker! Remember, we are talking about debugging someone else's code, not our own where we may know every bit. In real life, developers most often have to deal with code written by others.

Many authors (including one of the papers mentioned earlier in this thread - by Jenkov, as well as Brian Goetz that you had brought up) suggested that mixing checked and unchecked exceptions should be avoided because it adds to the confusion that ultimately may result in incorrect error handling. I agree with that point of view, except I see no way to use checked exceptions only. I'm sure you will agree, it's impossible to make all exceptions checked even if we wanted to. Therefore, in my view, using only RTEs seems to be the way to go, and I have proven to myself many times that it works perfectly. It has never failed for me. And it requires much less code to be written. If someone - who is in complete control of the system - choses to use a checked exception to enforce the additional contract between two adjacent modules, fine by be. I am convinced that the condition can be handled just as easily with a RTE instead. (And I generally prefer to impose less restrictions and shifting more responsibility/freedom to choose on the "consumer" modules; this is the school of thought that appeals to me more: let the driver decide which turn to take while providing the signs that suggest but not force.) To me consistency matters because, you are right, I most often work on projects where I have to either salvage something or to build a new product with a team less experienced developers who require guidance. And I need to ensure the least confusion and ambiguity in the system. Once in a while I get a chance to work on something new with a very strong team. But in all such most recent situations, "checked vs. unchecked" was not an issue. I didn't have to convince anybody.

So, the bottom line, if you want to use CEs, and you can ensure that you do it right, by all means, I am not going to tell you not to do it. But if someone asks me what I would recommend, I would whole-heartedly recommend to use RTEs.

(At least this thread IS about exceptions, so we didn't really hi-jack it with our discussion.)

Cheers,
C

P.S. Oh, and about the number of posts... yes I have only 139 by now, but that's because I rarely have time to post. I usually am swamped with work. From time to time I drop by and get sucked in... Then disappear for months. I guess staying busy is a good things, especially these days...

[al0]

Hi Constantine,

Olexandr,
just to make things clear, I did not intend this thread to burst in flames. I respect your opinion, and, it seems that - after all is said - we don't differ significantly in our opinions. You state that checked exceptions have the right to exist and may be of value in certain - however marginal - situations. And I don't reject this point.

May agree with your statement - with one notable amendment - situations where checked exceptions are useful constitute clear minority but are by no means marginal.

that the way checked exceptions were introduced and hyped up in Java was very irresponsible, and resulted in a disaster.

Rather not how they were introduced, rather how they were used. And as for me, "disaster" is too much of word here, in my opinion it was merely "trouble".

But it was long ago and at that point knowledge in this area was not deep enough. The same holds true for many, many other areas and technologies.
To name a few (both constrained to Java and much more generic):

• thread handling - inherently unsafe stop(), suspend(), resume(), lack of high-level primitives before Java 5 (presented as big achievement!), problems in JMM till Java 5. And save JMM all these mistakes are much less excusable then checked exceptions, because appropriate theory and practice have existed long before Java inception.
• Extremely ugly introduction of generics (not fixed yet and I'm not aware about any definitive plans to fix this problem, while it was claimed from start as short-term solution). And generics were no terra incognita -they have existed for decades in this or that form.
• And how much has left from original OOO concepts? With stateless approach and delegation instead of inheritance?

They didn't even think that re-throwing with a nested cause was necessary!!

Or rather (mistakenly) supposed that people would mostly re-throw exceptions as their own exceptions which they can (and would) chain manually if fill so. Not ability to chain exceptions, but ability to do so in standardized way was missing, And, anyhow, chaining support was lacking for both checked and unchecked exceptions.

2) Something that is only good for marginal and non-general-purpose solutions was introduced as the ultimate solution to error handling

Not sure what you mean by "non-general-purpose", but mostly agree.

Look at the code examples in books and on the Internet. The vast majority of them use exception handling that doesn't make sense.

Agreed, I have written myself "...is owing to the bad textbooks".

I believe that the checked exceptions implementation in Java has done more harm than good.

I would agree with this statement if it would be attributed not to "checked exception implementation", but to style in which there were used in JDK (and
to their presentation as "ultimate solution").

[QUOTE]
And I see it every day, unfortunately. Again, you don't have to agree. But I know that more and more people in the Java community are coming to similar conclusions every day. We finally see books coming out that say: use unchecked exceptions, the debate is over.
['/QUOTE]
For which reason practically all that I have spotted (with only couple of exceptions )says "use RTE for fault, checked for contingency". May you
provide some specific references?

In the past few years I have become very passionate about the issue because I see that improper error handling is one of the major/top contributors to messy chaotic, unmaintainable software projects.

120% (at least) true, BTW, for some inexplicable reasons I have much often seen completely screwed error handling not in Java, but in DB (namely, Oracle PL/SQL area).

I'm sure you will agree, it's impossible to make all exceptions checked even if we wanted to.

I will not agree - as I have agreed already and have written several times in this very thread that if only one kind of exceptions would exist it shall be RTE and that in case of any doubt use RTE.

Therefore, in my view, using only RTEs seems to be the way to go, and I have proven to myself many times that it works perfectly.

The only problem with RTE is that they are not part of the method contract and developer misses one of the ways to communicate his intention (yes, you may add them to the throws clause but you as way may forget to do it).

And it requires much less code to be written.

This is misconception, as I have already pointed out. Simple "handle to the point or just redeclare" policy minimizes this overhead (just to the exception name to the method signature).

So, the bottom line, if you want to use CEs, and you can ensure that you do it right, by all means, I am not going to tell you not to do it. But if someone asks me what I would recommend, I would whole-heartedly recommend to use RTEs.

Have nothing against it as soon as both pros and contras are mentioned (just to make sure that person becomes aware what to watch of).

Ok, now we came to some kind of agreement.

Thanks,
Oleksandr

[constv]

May you
provide some specific references?

For example, "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" - a very recent book. One may, certainly argue some details in it - about what exactly constitutes clean, based on personal preferences, but, generally it is a good book that was very well received.

The only problem with RTE is that they are not part of the method contract and developer misses one of the ways to communicate his intention (yes, you may add them to the throws clause but you as way may forget to do it).

Of course. However, I find that the reason this happens so often in Java is exactly because of what I call "checked exception mentality" of many programmers. Many people simply only handle what the compiler tells them to handle, and forget everything else. If there are no checked exceptions in the system, the programmer should very quickly realize the simple fact that everything can potentially result in an error, and failure must be always considered as a possible outcome of a method call. With such mentality "wired" in your brain it becomes very easy to properly use RTEs.

Simple "handle to the point or just redeclare" policy minimizes this overhead (just to the exception name to the method signature).

Do not intend to revive the discussion, just want to clarify my angle on this particular point of view... "Redeclaring" exposes the implementation details (in the form of that specific exception) of the underlying module to the modules that should not be otherwise even aware of that module. As the result, when that signature changes (a new exception is added) - you have a domino effect. That has long been one of the main arguments against checked exceptions: they break encapsulation and "versionability" of programs. Since it is often unrealistic to change signatures of tens of indirect dependencies throughout the system, developers often choose to swallow the "new" exception, or bury it under a more generic exception class that the method already declares, which defeats the purpose of a special checked exception class. As the result, the error is mishandled. So, I think, "handle to the point" when it is appropriate is the only really good scenario. Here's link to the famous interview with Anders Hejlsberg (chief architect of C#) where the subject is discussed in more detail (specifically, re-throwing issues, etc.). You probably have seen it, but just in case:

http://www.artima.com/intv/handcuffs.html

Thanks,
Constantine

[al0]

For example, "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)"

Thanks.

"Redeclaring" exposes the implementation details (in the form of that specific exception) of the underlying module to the modules that should not be otherwise even aware of that module. As the result, when that signature changes (a new exception is added) - you have a domino effect.

This is why checked exceptions are suitable only for situations that have some meaning for the application (typically some business meaning), some meaning that needs to be part of the contract. In which case it just can not stay "implementation detail". The rule formulated in my previous post was formulated on premise that checked exception are properly designed. It is absolutely obvious that if checked exception represents some implementation detail or technicality (which constitutes design bug) it should be caught and re-thrown as RTE. And in case of a contract change domino effect is rather desirable.

So full policy is as follow - if you met checked exception:

• if you can handle it "to the point", handle it
• if exception is appropriate (has sense as part of the method contract) do not catch it, but redeclare it (really, it should be declared already)
• if it represents implementation detail or pure technicality - wrap in RTE and re-throw

Here's link to the famous interview with Anders Hejlsberg (chief architect of C#) where the subject is discussed in more detail (specifically, re-throwing issues, etc.). You probably have seen it, but just in case:

http://www.artima.com/intv/handcuffs.html

Yes, I know it. Should admit that C# in many (not all) aspects is better language then Java. But, as for me, it goes in wrong direction now, but that completely different matter.

[infomercialscams]

If anyone want to know proper exception handling then do the search in google and exception handling you get so much of help from there. Most of exception handling is done in SQL, .Net, Oracle Database..