Announcement Announcement Module
Collapse
No announcement yet.
Spring Exception Framework Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Exception Framework

    Hi,

    While I was going through the sourcecode of the Spring Framework, i came across Exception Handling.
    I believe that Exception Handling was not design properly.

    Following is the scenario (the exceptions are extended in the following way)
    NestedRuntimeException<-DataAccessException<-DataIntegrityViolationException

    But if we see the code of last two classes, there is nothing but super(msg) or super(msg,..). And most of the implementation is there in NestedRuntimeException

    What is the necessity of defining a new class for the DataIntegrityViolationException?
    Is there any significance in having multiple exception class like above without having any implementation in it?

  • #2
    I can imagine that you want to handle a DataIntegrityViolationException differently then a DataRetrievalException. If we would only have a DataAccessException that would be harder to do.

    Comment


    • #3
      Isn't this a pretty common thing to do when defining an exception hierarchy. You provide specialised versions of the exceptions to allow these to be handled differently by the caller. There might be a sitation where DataIntegrityViolationException needs to be treated completely differently to it's parent.

      Comment


      • #4
        Considering that it would be a hierarchy,
        When there is no implementation in the class of DataIntegrityViolationException, then what is the necessity of having it.

        If i look at the exception hierarchy implementation, it looks like that only to define different name to the class it is created apart from that DataIntegrityViolationException has no use(because the implementation is in the parent folder). Is that a true statement or there is any other specific reason to create a class with no implementation in it.

        Comment


        • #5
          An important point of exception handling is differentiation of the exceptions to catch.

          If you want to generally handle DataAccessExceptions then
          Code:
            try {
               ...
            } catch (DataAccessException e) {
               ...
            }
          will suffice.

          If you have to discern exceptions because you need different handling routines then you might come up with something like that:
          Code:
            try {
               ...
          
            } catch (DataIntegrityViolationException e) {
               ... // special handling goes here
            } catch (DataAccessException e) {
               ... // handle the rest
            }
          I think this is a perfectly valid approach. Most exceptions around do not provide additional functionality compared with their superclasses.

          Just my 2 cents,
          Andreas

          Comment


          • #6
            I agree with Andreas. Also when doing exception handling with the ExceptionResolver in Spring I can quite well imagine that you want to display/redirect the user to another page in the case of a CannotGetJdbcConnectionException and a DataIntegrityViolationException for instance.

            If to have a concrete implementation is a criteria to justify a extension we could do away with most exceptions and just throw Exception and RuntimeException.

            Comment


            • #7
              I agree with both of them. I also don't really see the issue. You need to have more fine grained exceptions to deal with them in specific ways. What implementation can these add? All you need to do with them is be able to catch a more specific type. As I think everyone has said, it's a pretty common thing to do. Have a look how many sub-classes of IOException there are, do they add anything else?
              http://java.sun.com/j2se/1.4.2/docs/...Exception.html

              Comment


              • #8
                Yes, exception hierarchy in Spring is designed badly - but just for opposite reason, there are not enough distinct exceptions, especially under DataAccessException. There are JIRA-requests for it.


                Originally posted by nath View Post
                Hi,

                While I was going through the sourcecode of the Spring Framework, i came across Exception Handling.
                I believe that Exception Handling was not design properly.

                Following is the scenario (the exceptions are extended in the following way)
                NestedRuntimeException<-DataAccessException<-DataIntegrityViolationException

                But if we see the code of last two classes, there is nothing but super(msg) or super(msg,..). And most of the implementation is there in NestedRuntimeException

                What is the necessity of defining a new class for the DataIntegrityViolationException?
                Is there any significance in having multiple exception class like above without having any implementation in it?

                Comment


                • #9
                  Originally posted by al0 View Post
                  Yes, exception hierarchy in Spring is designed badly - but just for opposite reason, there are not enough distinct exceptions, especially under DataAccessException. There are JIRA-requests for it.
                  , so he wants less exceptions and you want more. No pleasing some people, I'd agree with you though. More fine-grained exception handling is definitely a bonus.

                  Comment

                  Working...
                  X