• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Interface Exception Signature - aka leaky abstractions

 
Josh Allen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What should I do when I want to let exceptions propagate up the call stack, but an interface I can't change won't let me?

E.g. create() can only throw a DuplicateKeyException. However my implementation can throw an IOException.

I can't see any good solution to this, so what I did was create a CreateRecordException that inherits from DuplicateKeyException and wrap the IOException in that. This isn't really correct because CreateRecordException isn't really a type of DuplicateKeyException, I just did that because I can't throw any other type of checked exception.

Another example is lock() which will probably want to throw an InterruptedException on wait().

The way I see it my choices are either
  • bury exception and/or set status flag(s)
  • Wrap the exception in a runtime exception and document that in javadoc
  • wrap the IOException in a DuplicateKeyException
  • do what I've done and have an unlogical inheritance hiarchy

  • None of which seem truely correct. How do people usually deal with this?
     
    Daniel Simpson
    Ranch Hand
    Posts: 181
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Josh Allen:
    What should I do when I want to let exceptions propagate up the call stack, but an interface I can't change won't let me?

    E.g. create() can only throw a DuplicateKeyException. However my implementation can throw an IOException.

    I can't see any good solution to this, so what I did was create a CreateRecordException that inherits from DuplicateKeyException and wrap the IOException in that. This isn't really correct because CreateRecordException isn't really a type of DuplicateKeyException, I just did that because I can't throw any other type of checked exception.

    Another example is lock() which will probably want to throw an InterruptedException on wait().

    The way I see it my choices are either
  • bury exception and/or set status flag(s)
  • Wrap the exception in a runtime exception and document that in javadoc
  • wrap the IOException in a DuplicateKeyException
  • do what I've done and have an unlogical inheritance hiarchy

  • None of which seem truely correct. How do people usually deal with this?
    I did choice three. I created custom exceptions that extended runtime exception. I caught checked exceptions and rethrew them as runtime exceptions. Is it even necessary to delare @throws for runtime exceptions in javadoc for a method? I would probably do something like:

    Hope that helps.
    [ January 16, 2005: Message edited by: Daniel Simpson ]
     
    Josh Allen
    Ranch Hand
    Posts: 37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Daniel Simpson:
    Hope that helps.

    Yeah that helps. It's not required to use @throws for RuntimeExceptions but see Javadoc - Documenting Unchecked Exceptions
     
    Daniel Simpson
    Ranch Hand
    Posts: 181
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Josh Allen:

    Yeah that helps. It's not required to use @throws for RuntimeExceptions but see Javadoc - Documenting Unchecked Exceptions


    I apologize, I meant that I did option 2, not option 3. But I'm sure you knew what I meant.
     
    Dieskun Koper
    Ranch Hand
    Posts: 85
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I believe there is no clean solution to this issue, other than avoiding it.
    In our application's case, for the lock method, you could catch and handle the InterruptedException in it, for the search and read methods, I solved it by caching the records (no more I/O), and the create and delete methods, I made them NOPs.

    When I was confronted with the issue of whether to include runtime exceptions in the javadoc, I had a look at the Java APIs' javadocs and found many methods including @throws for runtime exceptions.
    Maybe it's just in the classes I looked at, though. But if I would be throwing application exceptions as runtime exceptions, I would definitely include them in my javadoc.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic