jsr-333
  1. jsr-333
  2. JSR_333-29

Drop distinction between PathNotFoundException and ItemNotFoundException

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: api
    • Labels:
      None

      Description

      i remember that this has been discussed before but didn't manage to find
      the corresponding issue.

      while in theory the distinction between PathNotFoundException and ItemNotFoundException makes sense, i have
      the impression that it turns out to be quite artificial in reality. while working on the remoting of JCR
      calls over http it even turned out to be impossible to distinguish them, which lead to pretty ugly code
      in the JCR implementation: catching PathNotFoundException and rethrowing it as ItemNotFoundException (or vice
      versa) just because of the mere fact that the JCR API mandated the other exception.

      would it be feasible to merge the two exceptions? or make either of them a subclass of the other?

        Activity

        Hide
        Peeter Piegaze added a comment -

        What would the backward compatibility implications of this be? Does anyone have a clear idea?

        Show
        Peeter Piegaze added a comment - What would the backward compatibility implications of this be? Does anyone have a clear idea?
        Hide
        stefan_guggisberg added a comment -

        this seems to be a pure implementation issue and
        jsr-333 OTOH focuses on improving useability of the JCR api.

        while i agree that the distinction is artificial i am not sure
        whether it's worth changing the api/class hierarchy at this
        point.

        i'm -0 for doing such changes.

        Show
        stefan_guggisberg added a comment - this seems to be a pure implementation issue and jsr-333 OTOH focuses on improving useability of the JCR api. while i agree that the distinction is artificial i am not sure whether it's worth changing the api/class hierarchy at this point. i'm -0 for doing such changes.
        Hide
        Peeter Piegaze added a comment -

        There seems to be no further argument here, so I will close this as wontfix

        Show
        Peeter Piegaze added a comment - There seems to be no further argument here, so I will close this as wontfix

          People

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

            Dates

            • Created:
              Updated:
              Resolved: