Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-379 Cleanup and Document HDFS Client Intefaces and Protocol
  3. HDFS-401

Declare HDFS exceptions in the HDFS interface and also in class FileSystem and rethrow the encapsulated exception

    Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Server-side exceptions are encapsulated in the remote exception (as the class name and the error string ).
      The client side and FileSystem does not declare or thrown the these encapsulated exception.

      Work Items

      • Declare the exceptions in FileSystem and the HDFS interface (but still as subclasses of IOException)
      • Rethrow encapsulated declared exceptions if they are the declared exception.

        Activity

        Hide
        Konstantin Shvachko added a comment -

        Re-throwing should be rather easy since we have unwrapRemoteException().
        But catching and analyzing the "real" exceptions instead of RemoteException as we do now will involve a lot of code changes.

        Show
        Konstantin Shvachko added a comment - Re-throwing should be rather easy since we have unwrapRemoteException() . But catching and analyzing the "real" exceptions instead of RemoteException as we do now will involve a lot of code changes.
        Hide
        Steve Loughran added a comment -

        -you could search the code for the string "catch(RemoteException" and see what comes up. One of the real risks here is that its the failure mode code that is being changed, and that's always the code that doesn't get enough coverage, enough testing and enough real-world use, because its not until things start to go wrong in interesting ways that the code gets followed. Which makes it harder to say "we've fixed everything" once this change (Which seems good, BTW).

        One possibility: make the HDFS exception a subclass of RemoteException, with all the existing semantics. Old code may still work.

        Show
        Steve Loughran added a comment - -you could search the code for the string "catch(RemoteException" and see what comes up. One of the real risks here is that its the failure mode code that is being changed, and that's always the code that doesn't get enough coverage, enough testing and enough real-world use, because its not until things start to go wrong in interesting ways that the code gets followed. Which makes it harder to say "we've fixed everything" once this change (Which seems good, BTW). One possibility: make the HDFS exception a subclass of RemoteException, with all the existing semantics. Old code may still work.
        Hide
        Sanjay Radia added a comment -

        Here are two possible solutions that can be implemented in the RPC layer.
        1) if the client side has the class of the wrapped exception then rethrow it
        Unfortunately, this may endup throwing exceptions not declared in the signature.

        2) if the client side has the class of the wrapped exception and it is a declared exception then rethrow it.
        One must rethrow the deepest declared exception (since a method could declare multiple exceptions that are
        a subclass of one of the declared exception.)
        Q. suppose method foo() is declared as: foo() throws A, Ab, Ac;
        and Ab and Ac are subclasses of A.
        Say the server throws Az which is a subclass of A (note Az is not declared in foo's signature).
        Should the client side rethrow Az or A assuming that the class for Az is available?

        Show
        Sanjay Radia added a comment - Here are two possible solutions that can be implemented in the RPC layer. 1) if the client side has the class of the wrapped exception then rethrow it Unfortunately, this may endup throwing exceptions not declared in the signature. 2) if the client side has the class of the wrapped exception and it is a declared exception then rethrow it. One must rethrow the deepest declared exception (since a method could declare multiple exceptions that are a subclass of one of the declared exception.) Q. suppose method foo() is declared as: foo() throws A, Ab, Ac; and Ab and Ac are subclasses of A. Say the server throws Az which is a subclass of A (note Az is not declared in foo's signature). Should the client side rethrow Az or A assuming that the class for Az is available?
        Hide
        Tsz Wo Nicholas Sze added a comment -

        > Unfortunately, this may endup throwing exceptions not declared in the signature.

        It is not possible since the program won't be compiled.

        > One must rethrow the deepest declared exception

        Should it rethrow the original/wrapped exception? In the example "foo() throws A, Ab, Ac", if server throws Abb which is a subclass of Ab. I think we should throw Abb but not Ab.

        Show
        Tsz Wo Nicholas Sze added a comment - > Unfortunately, this may endup throwing exceptions not declared in the signature. It is not possible since the program won't be compiled. > One must rethrow the deepest declared exception Should it rethrow the original/wrapped exception? In the example "foo() throws A, Ab, Ac", if server throws Abb which is a subclass of Ab. I think we should throw Abb but not Ab.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sanjay Radia
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development