Announcement Announcement Module
Collapse
No announcement yet.
Proper exception handling Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Proper exception handling

    Does any body can suggest how to design good exception handling and logging of exceptions?

  • #2
    The question about exception handling is quite important IMHO. I have build a little process in Spring implementing the Fault Barrer. When I have some time, I will describe it here.

    The main idea is to :

    1) transform everything in Runtime Exception (functional and Technical), except an exception you want the caller to manage (contingency exception). Spring and Hibernate are doing this for you most of the time.

    2) Define your "Fault Barrier", normally it is the last level of command (the first caller). He will manage the exception (shows it on the screen, log it, send an email).

    You may want to read theses documents, they are interesting.
    •Rob Thornton , 2007-01, Effective Java Exceptions http://www.infoq.com/news/2007/01/effective-exceptions
    •Barry Ruzek, 2007-01, Effective Java Exception, http://www.oracle.com/technology/pub...xceptions.html

    Other and older articles:
    •Gunjan Doshi, 2003; Best Practices for Exception Handling: http://www.onjava.com/lpt/a/4345
    •Müller, Simmons, 2002, Exception Handling: Common Problems and Best Practice with Java 1.4 http://www.netobjectdays.org/www_old...ustry/1430.pdf

    and http://tutorials.jenkov.com/java-exc...xceptions.html
    Last edited by etienno; Feb 12th, 2009, 10:21 AM.

    Comment


    • #3
      Read these threads...

      http://forum.springframework.org/showthread.php?t=63549

      http://forum.springframework.org/showthread.php?t=64932

      You may also take a look at these:

      http://forum.springframework.org/showthread.php?t=54392

      http://forum.springframework.org/showthread.php?t=54993


      BTW, etienno, none of the books or articles you mention are good enough. All of them contain a small amount of "poison" that only leads to more confusion. they all try to find justifications and valid scenarios for checked exceptions, and there aren't any. NONE! because checked exceptions contradict the mere purpose of the exceptions mechanism. Hope the links above clarify my point. There has been many discussions on this subject in these forums.

      Constantine
      Last edited by constv; Feb 12th, 2009, 11:23 AM.

      Comment


      • #4
        Thanks for repliess..

        Comment


        • #5
          Originally posted by constv View Post
          All of them contain a small amount of "poison" that only leads to more confusion. they all try to find justifications and valid scenarios for checked exceptions, and there aren't any. NONE! because checked exceptions contradict the mere purpose of the exceptions mechanism.
          Hi Constantine,

          have to disagree with you once more - checked exceptions serve good defined and very valid purpose - to specify some condition that is untypical (i.e. is not on the code "Happy-Path) but not totally unexpected by caller and to which caller MUST be prepared and from which caller is able to recover. Yes, it is some kind of niche usage, but it still exists. If you see a better alternative for such situations please share your thoughts.

          later addition:
          BTW, I have noticed that all references provided to you are to your own opinions - nobody else has contributed to those threads (save question originators), there were no other opinions - neither pro, nor contra
          Last edited by al0; Feb 24th, 2009, 04:50 AM.

          Comment


          • #6
            Originally posted by etienno View Post
            You may want to read theses documents, they are interesting.
            •Rob Thornton , 2007-01, Effective Java Exceptions http://www.infoq.com/news/2007/01/effective-exceptions
            Really not a much info here, merely reference to your second link.
            •Barry Ruzek, 2007-01, Effective Java Exception, http://www.oracle.com/technology/pub...xceptions.html
            This is really interesting and useful, and there are some very useful links at the end of it - and those links represent both points of view - pro and contra (for checked exceptions), so you may weight them on your own.
            Other and older articles:
            •Gunjan Doshi, 2003; Best Practices for Exception Handling: http://www.onjava.com/lpt/a/4345
            Very basic and lack any reasoning (just collection of advices), but not so bad.
            •Müller, Simmons, 2002, Exception Handling: Common Problems and Best Practice with Java 1.4 http://www.netobjectdays.org/www_old...ustry/1430.pdf
            Mixes several concepts related to exception handling together, is somewhat outdated, contains some questionable advices, like "1 They might be justified if an exception is harmless and doesn’t need treatment (e.g.
            InterruptedException), but never if an exception supposedly cannot occur.", where "They" refers to the empty exception block. You may try to find Brian Goetz argumentation why exception block for InterruptedException should not ever be empty, it is present in the chapter 5.4 of his famous "Java Concurrency in Practice" book and (as far as I can remember) somewhere on www.ibm.com/developerworks, sorry, I do not have a link on hands right now.

            [/QUOTE]
            As well quite good discussion with lot pro and contra and some further useful links.

            Comment


            • #7
              Originally posted by al0 View Post
              Hi Constantine,

              have to disagree with you once more - checked exceptions serve good defined and very valid purpose - to specify some condition that is untypical (i.e. is not on the code "Happy-Path) but not totally unexpected by caller and to which caller MUST be prepared and from which caller is able to recover. Yes, it is some kind of niche usage, but it still exists. If you see a better alternative for such situations please share your thoughts.

              later addition:
              BTW, I have noticed that all references provided to you are to your own opinions - nobody else has contributed to those threads (save question originators), there were no other opinions - neither pro, nor contra
              Hi Olexandr,
              you are correct, I have provided the links to my own arguments - in order not to repeat them. However, there were other opinions and questions there - the ones to which I responded.

              ...to which caller MUST be prepared and from which caller is able to recover.
              I - and many others all over the world/Internet - have stated many times that the "callee" has no business of assuming what the immediiate caller MUST recover from, how, and when! This is one of the biggest flaws in the checked theory. Let the client decide what it needs to do. In most cases, the client may have to act upon the exception - not immediately at the source of the error - but a few or many layers away. The client's design must be based on its own requirements and expectations - not the implementation details of its dependencies. So, the "marginal" cases you are talking about are applicable to the simplest of communications between to adjacent methods. Then it is nothing more than a sugar-coated error code that is enforced by the compiler. But it is NOT what exceptions are for.

              So, your argument for the marginal conditions in which one may expect some benefit from checked exceptions to me only proves their worthlessness. In fact, in each such hypothetical condition - even if it exists - a RTE can be used just as well if not more efficiently - without any inherited risks of checked exceptions poisoning the rest of the system by their mere existence. To get correctness of error handling out of checked exceptions several conditions must be obeyed:

              1) Arguably, it must be one of the very rare marginal situations you have mentioned;
              2) Great caution must be exercised by an experienced developer to execute the handling properly in order to make sure that the error is handled in the right place, that it is propagated precisely to the right handler with no info lost, etc.

              In the meantime, there is a huge risk - it is all but guaranteed - that the presence of checked exceptions in the system will prompt developers to mishandle errors everywhere else throughout the system and introduce too much unnecessary and harmful clutter.

              The point is that all effective error handling can be done without checked exceptions, including any marginal cases. If you accidentally let a particular RTE propagate too far, it is much easier to notice that quickly - the very first time it happens during testing. Any proper error handling requires developer's competence. Ironically, checked exceptions have always been promoted as a tool to assist inexperienced programmers, especially. In reality, they teach inexperienced programmers the very wrong things about error handling. You have to really know what you are doing to use checked exceptions correctly. And if you really know what you are doing, you will see that RTEs are all you need. Incompetent developers are absolutely guaranteed to misuse checked exceptions. A competent developer that uses checked exceptions has to do much more work and write much more code to ensure the correctness - than when using RTEs. So why not do it the right and easy way from the beginning. An incompetent guy will screw it up in both cases, but with unchecked exceptions it will be easier and faster to detect and fix without affecting much of the system.

              Some of the articles etienno brought up and you commented on are better than others. But the main problem with all of them - to me - is that they don't explain what exceptions were originally designed to do, and they all try to stay "diplomatic" about the issue. (These days, it is no longer such a touchy subject.) The authors who doubted the usefulness of checked exceptions clearly didn't want to alienate the readers and put too much sugar in their articles. Jenkov states: use one type only, either checked or unchecked... Well, this is ridiculous. You can't use only checked exceptions because even JDK has RTEs all over the place. (Otherwise, Java would have not been a usable language.) So, if you have to use only one type, your only - and correct - choice is RTEs.
              Last edited by constv; Feb 27th, 2009, 03:30 PM.

              Comment


              • #8
                Originally posted by constv View Post
                I - and many others all over the world/Internet - have stated many times that the "callee" has no business of assuming what the immediiate caller MUST recover from, how, and when!
                Caller need not to be immediate - all this bla-bla-bla about catching/re-raising miss the opportunity for immediate to declare exception in his signature - just simply (but intentionally!) delegating processing to the his caller.

                This is one of the biggest flaws in the checked theory. Let the client decide what it needs to do.
                In case of a checked exception you not only let him to decide, but force him to decide - to catch and process or just redeclare.
                In case of unchecked exception he may decide or may forget that he has something to decide on.

                You are right - callee can not know what client would do, but it may reasonable assume that some kind of exceptions is unlikely to be propagated many levels up. In which cases checked exceptions may be used.
                Then it is nothing more than a sugar-coated error code that is enforced by the compiler. But it is NOT what exceptions are for.
                Absolutely blank statement. Checked exceptions are just about it - do not allow caller thoughtlessly miss processing of exceptional situation - he may decide for not processing - but it must express this intention explicitly.

                [QUOTE]
                So, your argument for the marginal conditions in which one may expect some benefit from checked exceptions to me only proves their worthlessness.
                These conditions do not constitute majority, but by no means are marginal.

                a RTE can be used just as well if not more efficiently
                As I have already said RTE can not force caller make explicit decision.

                [QOUTE]
                - without any inherited risks of checked exceptions
                There are no more (if not less) inherent risks in checked exceptions then in RTE.

                1) Arguably, it must be one of the very rare marginal situations you have mentioned;
                Yes, minority, but important minority.

                2) Great caution must be exercised by an experienced developer to execute the handling properly in order to make sure that the error is handled in the right place, that it is propagated precisely to the right handler with no info lost, etc.
                A lot of fuss about (almost) nothing - just redeclare if do not want to process. No great experience is required for that.

                In the meantime, there is a huge risk - it is all but guaranteed - that the presence of checked exceptions in the system will prompt developers to mishandle errors everywhere else throughout the system and introduce too much unnecessary and harmful clutter.
                This is rather matter of policy and education. And with RTE you are exposed to another risk - to process them to late. For simple web applications it is not
                so critical, but, for example, for a batch processing may be absolutely fatal.

                The point is that all effective error handling can be done without checked exceptions,
                And programming .- without high-level languages, IDE, ... - assembler and edlin are good enough

                If you accidentally let a particular RTE propagate too far, it is much easier to notice that quickly - the very first time it happens during testing.
                The same holds true for checked exceptions - you would notice swallowed exception during unit tests.
                Any proper error handling requires developer's competence.
                100% true, but the same is true for any other software development activity.

                Ironically, checked exceptions have always been promoted as a tool to assist inexperienced programmers, especially.
                The checked exceptions are in the same league as strongly typed variables, no more, no less.

                In reality, they teach inexperienced programmers the very wrong things about error handling.
                Checked exceptions teach nothing - never, ever. Teachers and book writers teach. So you have selected wrong target to blame.
                And if you really know what you are doing, you will see that RTEs are all you need.
                Sorry, but I do not see it. You perfectly know that labels and goto are sufficient to express any control flow, but this fact does not preclude you from use of structured control flow statements. The same with exceptions - RTE are sufficient, but this fact should not preclude usage of checked exceptions when they are more suitable (I would say 10% of cases).
                Incompetent developers are absolutely guaranteed to misuse checked exceptions.
                Absolutely not. You normally need from 10 to 15 minutes to explain him how to handle them. But you are right - such developer can not decide which kind of exception should be thrown. But luckily enough, it should not be his responsibility anyway.

                A competent developer that uses checked exceptions has to do much more work and write much more code to ensure the correctness - than when using RTEs.
                Do not see why, sorry.

                but with unchecked exceptions it will be easier and faster to detect and fix without affecting much of the system.
                With checked exceptions you have to ensure that it is not swallowed, with unchecked - the it is not missed. More or less the same amount of work by unit testing. What holds (partially) true - if improper handling find its way to the production, then missed handling of unchecked exception may be detected more easily then mistakenly swallowed checked exception. Partially, because if unchecked exception kills not your "main" thread it may pass unnoticed (if you or that infamous "inexperienced guy" forgot to built "barrier" into that very thread).
                is that they don't explain what exceptions were originally designed to do, and they all try to stay "diplomatic" about the issue. (These days, it is no longer such a touchy subject.)
                AFAIK, exceptions were designed to to mitigate the main problem of returning of error codes - nobody acts on them. And checked exceptions meet this bill more precisely. Another story that bill itself was not very correct.

                So, if you have to use only one type, your only - and correct - choice is RTEs.
                Sure. But luckily, we are not constrained to one type only, so we can select which suites specific need better. But in case of any doubt RTE should be used.

                And once more about misuse - it is quite easy to avoid checked exceptions misuse by coding, but much harder by design. So before deciding in favor of checked exceptions person should "look and only then leap".

                But complete avoidance of checked exceptions is classical symptom of the FUD.

                Comment


                • #9
                  Your post is not serious. The same old rant of a defender of the long-discredited idea. With no substance or proof. We will never agree. I had stopped using checked exceptions years ago (and admit that I was duped into using them by the hoopla, at first.) And may I say so, I have many critical projects behind my belt by now - to prove that I am right. I don't just pull my statements out of my ass. It takes much less code to bullet-proof application with RTEs. The biggest most outrageous lie about CEs is that they introduce safety. Unless you live and work in a bubble, you should see how error handling is misused on Java projects out there - with stupid try/catches all over the place - for no reason, while real errors get uncaught, and the essential error info getting lost. Checked exceptions unfortunately do teach - and really bad things. By implying that the developer should handle some and disregard other errors, that some calls may result in errors and some may not. That is the conclusion most Java developers - however subconsciously - come to while using checked exceptions. Using checked exceptions is almost always all but thoughtless. RTEs first of all carry a different implication - that anything may fail and the developer must always consider that. Once you consider that, the next thing you need to decide: can I do something about a failure here? If not, do nothing. But the thing is: you make such decisions with every single module you code and finally make a decision to catch any errors that bubble up to the module that can and should do something about them. And you start with putting a handler around everything. Nothing should remain unhandled. And NO, exceptions should NOT force anything. That's just garbage! They should carry the fullest error info from the source of the error to whomever is designated to handle it - without putting a burden on anyone else who should not be concerned. That is what they are for. You can only force an immediate caller to do something - like to be aware of a particular interface and provide particular data types. Your arguments have long been discredited millions of times before, and I am not going to argue every point you make. We have heard all that and more, and each and every one of those arguments just doesn't hold water. It's a waste of time for me to discuss this any more.

                  Comment


                  • #10
                    Originally posted by constv View Post
                    Your post is not serious. The same old rant of a defender of the long-discredited idea.
                    Discredited by whom? By you - sorry, you do not have enough authority to discredit this idea.
                    With no substance or proof.
                    You unintentionally have admitted trust - "that so-called discreditation has no substance of proof, i.e. is absolutely unfounded".
                    to prove that I am right.
                    It only proves that checked exceptions may be avoided, it does not prove in any way that they shall avoided by any means. I hope you see a difference,
                    I don't just pull my statements out of my ass. It takes much less code to bullet-proof application with RTEs.
                    Provide some proof, please.
                    The biggest most outrageous lie about CEs is that they introduce safety.
                    They do not introduce safety, but they may help to write safer code if are properly used.
                    is misused on Java projects out there
                    It would be better to say "may be misused". But there are a lot of other techniques subjected to heavy misuse. The proper remedy is to educate peoples and not to blindly ban techniques.

                    - with stupid try/catches all over the place - for no reason, while real errors get uncaught,
                    I have seen such code, but it has not survive long in any of the projects that
                    I have participated. But such code "style" (may I cal it "disstyle"?) is owing to the bad textbooks rather then to checked exceptions as such.

                    By implying that the developer should handle some and disregard other errors, that some calls may result in errors and some may not.
                    It may be put in other way - "should be aware of and interested in some kind of exceptional situations and not interested in others" (I dislike word "error" in this context, not each exceptional situation is an error).
                    Using checked exceptions is almost always all but thoughtless.
                    This is very typical FUD argument. "I fear it, I doubt it, I'm uncertain about it - so it is bad".
                    RTEs first of all carry a different implication - that anything may fail and the developer must always consider that.
                    When you drive a car anything can fail - you may bi hit by another car or by
                    a meteorite. But, because you are unable to do anything about meteorite you concentrate your attention on the car. BTW, if follow your logic road should not carry any road signs - they (ok, some of them) are similar to checked exceptions as they say "be aware of this or that specific hazard", while other hazards also exist.

                    Once you consider that, the next thing you need to decide: can I do something about a failure here? If not, do nothing. But the thing is: you make such decisions with every single module you code and finally make a decision to catch any errors that bubble up to the module that can and should do something about them.
                    Sorry, 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,
                    And NO, exceptions should NOT force anything. That's just garbage!
                    It is your personal opinion - and terribly wrong one.

                    They should carry the fullest error info from the source of the error to whomever is designated to handle it - without putting a burden on anyone else who should not be concerned.
                    The only problem is that this "designee" should be aware in advance of exceptions that may reach him. With unchecked exceptions such information may be lost/overseen. It is not a problem in a case of unrecoverable (or recoverable only after user interaction) exceptions. I. e. exceptions that may be handled "one size suits all" manner. But such handling is not always suitable.

                    That is what they are for. You can only force an immediate caller to do something - like to be aware of a particular interface and provide particular data types.
                    Not "to do something", but "express his intentions explicitly" - do you catch the difference?

                    Your arguments have long been discredited millions of times before,
                    No more (And no less) then yours.
                    just doesn't hold water. It's a waste of time for me to discuss this any more.
                    Yes, they are not intended to hold water (there is enough water in your arguments), they are intended to hold trust

                    BTW, did you noticed one major difference between our approaches (not only in this specific case)?

                    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" .

                    Comment


                    • #11
                      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.
                      Last edited by constv; Feb 28th, 2009, 12:47 PM.

                      Comment


                      • #12
                        Originally posted by constv View Post
                        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.

                        Comment


                        • #13
                          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...
                          Last edited by constv; Feb 28th, 2009, 05:34 PM.

                          Comment


                          • #14
                            Hi Constantine,
                            Originally posted by constv View Post
                            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

                            Comment


                            • #15
                              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

                              Comment

                              Working...
                              X