jsr-333
  1. jsr-333
  2. JSR_333-14

Checked versus unchecked exceptions

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: api
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Generally there are a lot of checked exceptions throughout the API. It may be worth thinking about
      introducing more unchecked exceptions, potentially even extending RepositoryException from
      RuntimeException. Thoughts?

        Activity

        Hide
        uncled added a comment -

        changing component

        Show
        uncled added a comment - changing component
        Hide
        rhauch added a comment -

        I would love to see all checked exceptions changed to runtime exceptions, though they still need to be
        documented and (preferably) included on the throws clauses.

        Show
        rhauch added a comment - I would love to see all checked exceptions changed to runtime exceptions, though they still need to be documented and (preferably) included on the throws clauses.
        Hide
        thomasmueller2 added a comment -

        For me, the motivation is ease of use (the users of the API will no longer need
        to catch or re-throw the exception), but we need to discuss the advantages /
        disadvantages.

        We need to investigate whether or not this does break compatibility. I guess in
        theory it does break compatibility, but I'm not sure about the consequences in
        practice for existing code. As it was and is done for similar changes in the
        Java language or API, we could define a source code corpus (similar to the
        http://qualitascorpus.com/) that allows us to verify if it does in fact break
        compatibility.

        Show
        thomasmueller2 added a comment - For me, the motivation is ease of use (the users of the API will no longer need to catch or re-throw the exception), but we need to discuss the advantages / disadvantages. We need to investigate whether or not this does break compatibility. I guess in theory it does break compatibility, but I'm not sure about the consequences in practice for existing code. As it was and is done for similar changes in the Java language or API, we could define a source code corpus (similar to the http://qualitascorpus.com/ ) that allows us to verify if it does in fact break compatibility.
        Hide
        reschke added a comment -

        "Ease of use" sounds subjective to me.

        I personally hate it when I don't know what needs catching (Hibernate...).

        It appears that we're planning for 180 degree turn; maybe we should start
        identifying a problem (such as lookups throwing exception instead of returning
        null?).

        Show
        reschke added a comment - "Ease of use" sounds subjective to me. I personally hate it when I don't know what needs catching (Hibernate...). It appears that we're planning for 180 degree turn; maybe we should start identifying a problem (such as lookups throwing exception instead of returning null?).
        Hide
        thomasmueller2 added a comment -

        > I personally hate it when I don't know what needs catching (Hibernate...).

        Runtime versus checked exceptions is very subjective. Most programming languages
        don't have checked exceptions at all (for example, C# and Scala don't have
        them). For me, checked exceptions are more a nuisance than a help, specially if
        each and every method in an API can throw an exception, or even worse, multiple
        exceptions. As a user of the API, I have to catch or re-throw the exception,
        even thought I can't possibly do much about it. As an example,
        Session.getRootNode() can throw a RepositoryException. Most likely this is my
        mistake because I closed the repository already. This situation is somewhat
        similar to NullPointerException (which is unchecked). Another possible reason
        is: the connection to the repository or backend store is lost, which is not
        really preventable or recoverable. See also
        http://stackoverflow.com/questions/2884836/why-nullpointerexception-is-a-runtime-exception-and-remoteexception-not

        > lookups throwing exception instead of returning null

        Yes, this would sound like a problem.

        Show
        thomasmueller2 added a comment - > I personally hate it when I don't know what needs catching (Hibernate...). Runtime versus checked exceptions is very subjective. Most programming languages don't have checked exceptions at all (for example, C# and Scala don't have them). For me, checked exceptions are more a nuisance than a help, specially if each and every method in an API can throw an exception, or even worse, multiple exceptions. As a user of the API, I have to catch or re-throw the exception, even thought I can't possibly do much about it. As an example, Session.getRootNode() can throw a RepositoryException. Most likely this is my mistake because I closed the repository already. This situation is somewhat similar to NullPointerException (which is unchecked). Another possible reason is: the connection to the repository or backend store is lost, which is not really preventable or recoverable. See also http://stackoverflow.com/questions/2884836/why-nullpointerexception-is-a-runtime-exception-and-remoteexception-not > lookups throwing exception instead of returning null Yes, this would sound like a problem.
        Hide
        Peeter Piegaze added a comment -

        So, just for the sake of argument. If we were to do this, it would involve changing RepositoryException from

        public class RepositoryException extends Exception

        to

        public class RepositoryException extends RuntimeException

        Is that it?

        And what impact would this have on existing code that uses the JCR API?

        Show
        Peeter Piegaze added a comment - So, just for the sake of argument. If we were to do this, it would involve changing RepositoryException from public class RepositoryException extends Exception to public class RepositoryException extends RuntimeException Is that it? And what impact would this have on existing code that uses the JCR API?
        Hide
        Peeter Piegaze added a comment -

        I am inclined to make this change. It would seem to be one of the most significant things we could do to actually make the API easier to use, and that is supposed to be one of the goals of JSR-333.

        Would it make sense to keep some of the exceptions as checked and change only those that truly meet some criteria (non-religious, hopefully) that we decide upon?

        Any ideas?

        Show
        Peeter Piegaze added a comment - I am inclined to make this change. It would seem to be one of the most significant things we could do to actually make the API easier to use, and that is supposed to be one of the goals of JSR-333. Would it make sense to keep some of the exceptions as checked and change only those that truly meet some criteria (non-religious, hopefully) that we decide upon? Any ideas?
        Hide
        Peeter Piegaze added a comment - - edited

        Fixed.

        RepositoryException.java:
        - public class RepositoryException extends Exception
        + public class RepositoryException extends RuntimeException
        
        Show
        Peeter Piegaze added a comment - - edited Fixed. RepositoryException.java: - public class RepositoryException extends Exception + public class RepositoryException extends RuntimeException

          People

          • Assignee:
            Unassigned
            Reporter:
            uncled
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: