2

I have been looking through major Android SDK's (Facebook, Google+, and even Android). What I have noticed is that exceptions never seem to be included in method signatures. Instead what I see is that Exceptions are thrown, but usually only listed in the docs (if you are lucky).

What is up with this practice? Is there some manifesto declaring exceptions in method signatures evil?

Examples: From android.database.AbstractCursor

void checkPosition()

This function throws CursorIndexOutOfBoundsException if the cursor position is out of bounds.

Why this and not 

void checkPosition() throws CursorIndexOutOfBoundsException

I prefer the latter since you can set up your IDE/compiler to actually warn you instead of just praying to the bytecode that the docs mention what is acutally being thrown.

Joffrey
  • 32,348
  • 6
  • 68
  • 100
stevebot
  • 23,275
  • 29
  • 119
  • 181
  • 1
    There's a lot of disagreement in the java world over whether to use checked or unchecked exceptions. Welcome to the debate. :p see http://stackoverflow.com/questions/6115896/java-checked-vs-unchecked-exception-explanation – azurefrog Apr 24 '14 at 14:38
  • 2
    Isn't this question, in fact, mostly opinion based ? – Denys Séguret Apr 24 '14 at 14:50
  • @dystroy Partly. It depends on whether the OP knows or not that RuntimeExceptions do not need to be declared, as opposed to checked Exceptions. If yes, then he's asking about our opinion on whether to declare RuntimeExceptions or not. – Joffrey Apr 24 '14 at 14:52
  • @Joffrey Due to the *I prefer the later* I think he knows it. – Denys Séguret Apr 24 '14 at 14:53
  • @dystroy Very true, indeed. The question might need rewording then. – Joffrey Apr 24 '14 at 14:57

2 Answers2

6

It's because CursorIndexOutOfBoundsException is a RuntimeException. It is not a checked exception.

http://developer.android.com/reference/android/database/CursorIndexOutOfBoundsException.html

jgitter
  • 3,396
  • 1
  • 19
  • 26
  • This is why you have the choice to include it, not why it should or shouldn't be there. – Joffrey Apr 24 '14 at 14:38
  • It is not standard practice to declare thrown RuntimeException types. They are truly exceptional and you should be defensively writing code to protect yourself from them. As @azurefrog said, "Welcome to the debate". – jgitter Apr 24 '14 at 14:40
  • For what little this is worth to you, I tend to prefer checked exceptions as well. :-) – jgitter Apr 24 '14 at 14:41
  • The debate @azurefrog talks about is whether or not to use checked or runtime exception, not about declaring RuntimeExceptions in the signature. – Joffrey Apr 24 '14 at 14:42
  • 1
    I'm unsure, but I think the OP knows that RuntimeException don't *have to* be added in the signature. I believe he's asking whether it should be done or not. – Joffrey Apr 24 '14 at 14:45
  • At the end of the day every method throws RuntimeExceptions already so there is no point in adding a throws declaration for every potential RuntimeException. Partly because there is no way to know just what runtime issues may arise. Maybe you'll run out of memory. Maybe the thread will get terminated. Do you really want to see those added as declared exceptions on every java method? It is the fault of the API developer for not documenting unchecked exceptions properly. – jgitter Apr 24 '14 at 14:46
  • Here starts the debate ;) but I mostly agree with you, I wouldn't declare all of those. I usually declare the ones I personally throw in the code of the method, if it makes sense to document it. – Joffrey Apr 24 '14 at 14:50
  • What if those aren't thrown there though? They could have been thrown by another library being used under the hood... In any case, I admit I was being a little outrageous to make a point. – jgitter Apr 24 '14 at 14:52
  • That's what I meant by *the ones I personally throw in the code of the method*. It is often not the case that a RuntimeException needs documentation anyway. – Joffrey Apr 24 '14 at 14:54
  • My point was that if they are thrown by a 3rd party lib then the OP still has the same problem. – jgitter Apr 24 '14 at 14:56
  • Alright, then I think your point here better answers the OP than your current answer ;) – Joffrey Apr 24 '14 at 14:58
1

In your precise example, this is informative.

This exception can only be thrown in case of a severe bug in the calling code, so there's no point in writing a try/catch for that runtime exception which should not happen in production and there's no point in cluttering the signature.

Denys Séguret
  • 372,613
  • 87
  • 782
  • 758