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.Discredited by whom? By you - sorry, you do not have enough authority to discredit this idea.
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.rovide some proof, please.
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.They do not introduce safety, but they may help to write safer code if are properly used.
Whatever...as long as "may be" means in more than 90% of all cases.It would be better to say "may be misused".
True. Not all techniques however are designed to encourage misuse, like checked exceptions.But there are a lot of other techniques subjected to heavy misuse.
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".I have seen such code, but it has not survive long in any of the projects that
I have participated.
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.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,
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.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" .
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.