4

This might be unsuitable for SO since it isn't really a coding-problem, but I couldn't find a satisfying answer yet and I believe the SO-community can.

So, by definition android.database.SQLException and java.sql.SQLException share about the same scope of application, which is to provide information about errors while accessing/modifying a database. Though I've read somewhere that checked exceptions are "out", I really like the fact that the compiler reminds you of handling exceptions when you use checked exceptions with the throws keyword. Unfortunately this doesn't work with unchecked exceptions.

My question is: Why did Google make their android.database.SQLException unchecked when java.sql.SQLException is checked? Am I missing something? Do they differ more than I think?

Gerrit-K
  • 1,298
  • 2
  • 15
  • 30

4 Answers4

3

The choice between making an exception checked or unchecked is always somewhat subjective:

  • If an exception indicates a bug, or some failure that is "probably not recoverable", then a unchecked exception is appropriate.

  • If an exception indicates a failure that is "probably recoverable", then a checked exception is appropriate.

It is more difficult in cases like this where there is a general exception with lots of subclasses. Some of those subclasses could be bugs, or they could be recoverable. At this point, the designer has to make a value judgement about the relative likelihood of the different cases ... across all known / predicted subtypes of the exception.

In this case, the Sun and Google engineers came to different conclusions. But note that the Google engineers had a big advantage that the Sun engineers didn't have. They could look at the Java design, and make their own judgement on how well it worked with a checked SQLException.

Though I've read somewhere that checked exceptions are "out" ...

There are a lot of developers who wish that all Java exceptions were unchecked so that they didn't have to be forced to deal with them. There are a lot of other developers who still think that Java got it right with checked exceptions ... even though there were a few cases where the wrong choice was made (in hindsight).

It is debatable.

Am I missing something? Do they differ more than I think?

Not really. The two exception hierarchies serve pretty much the same purpose ... differences in javadoc class descriptions notwithstanding.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I know I can't expect a perfect answer on this question since it is about a subjective decision someone made. But your answer contains some major points about the choice between checked and unchecked exceptions, which I didn't thought of yet, so I'll accept it. Thanks ;) – Gerrit-K Mar 03 '13 at 15:30
2

android.database.SQLException is based on java.lang.RuntimeException and don't need to be checked, but java.sql.SQLException isn't.

At Unchecked Exceptions — The Controversy there is a simple explanation about this.

TAL
  • 41
  • 3
  • I know the basic difference between checked and unchecked exceptions in java when it comes to inheritance, so your answer isn't really what I was looking for. However, the link you posted contains some useful information. Thanks. – Gerrit-K Mar 03 '13 at 14:56
0

I think that unchecked Exceptions are to prefer over checked Exceptions in many cases. The reason is that you aren't forced to catch it in any way. You can surround your code with a try-catch clause if you think it's necessary, but you don't have to. This effectively makes your code better, as the programmer can decide what to do.

In your example, there is no particular reason why one has to make it checked or not. It is a question of design, whereby I think Google did a better job with android.database.SQLException.

poitroae
  • 21,129
  • 10
  • 63
  • 81
0

The reason I think it is so is because :

android.database.SQLException : An exception that indicates there was an error with SQL parsing or execution.

and

java.sql.SQLException : An exception that provides information on a database access error or other errors.

So, it is clear that android.database.SQLException is likely a RuntimeException because it occurs when there is an error with SQL parsing or execution. Whereas, java.sql.SQLException is an exception caused due to database access error or other such errors, so it is valid enough to keep it as a checked exception. Anytime you work with open connections, or any things of such sort, it's better to have them under the umbrella of checked exception.

Kazekage Gaara
  • 14,972
  • 14
  • 61
  • 108
  • I understand why android's exception should be a RuntimeException but what makes the difference to java's exception? I mean, in android it will also be thrown when the program cannot connect to the database, so isn't this as "valid" as the other one? PS: If I post links you can expect me to have taken a look at them ;) – Gerrit-K Mar 03 '13 at 14:44