0

I have a hard time interpreting the meaning of these two (seemingly simple) sentences:

"Checked exceptions are checked by the compiler at compile time"

What does this mean? That the compiler checks if all checked exceptions (that are thrown in de code) are caught?

"Unchecked exceptions are checked at runtime, not compile time"

What does "checked" mean in this sentence? I thought unchecked exceptions were just thrown at runtime?

BigJ
  • 1,990
  • 2
  • 29
  • 47

4 Answers4

1
  • At compilation time

There are two types :

  1. Checked: means if the method thrown to the required exception

  2. Unhandled checked exception: if the method didn't thrown to the required exception, results in a compilation error.

    • At run time

Called Unchecked Exception occurs at runtime and need not to be explicitly handled. RuntimeException and its subclasses or Error and its subclasses all fall under Unchecked.

Azad
  • 5,047
  • 20
  • 38
1

In my opinion, the 2nd statement is incorrect. Or if it is correct, it is using "checked" to mean something different to what it means in the first sentence. And that's an misleading and unhelpful thing to do.

I could maybe be persuaded otherwise if you provided the context (and source) for these sentences.

I thought unchecked exceptions were just thrown at runtime?

They also are (can be) caught at runtime ... and maybe that's what the quote means. But if that is what it means, then it is twisting the normal meaning of "checking" ... see previous note about "misleading and unhelpful".

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

It might be clearer to read them as this:

"Checked exceptions are (tested to see if there is a matching try/catch) by the compiler at compile time" - if not, the code will not compile

"Unchecked exceptions are (tested to see if there is a matching try/catch) at runtime, not compile time" - if not, the code will crash

James
  • 88
  • 7
  • That's fine, if you want to re-throw it you have to catch it first, then if you decide to throw it again, or any other checked exception, there will need to be a matching catch for that - its a second checked exception. – James Jul 02 '13 at 23:15
  • no, that's my point: you don't have to catch it first. You can just declare "throws" on the method. – Puce Jul 03 '13 at 07:10
  • Of course, but then further up the stack, at some point you will need a matching catch for the code to compile. The catch doesn't have to be in the same function. – James Jul 03 '13 at 08:06
  • Even this is not correct. Firstly, you can write libraries which compile fine where there are only "throws" declarations and no "catch" clauses. Secondly, you could have your main method throw exception as well and avoiding catch exception at all. From the scompiler point of view: if there is a checked exception either catch it or throw it – Puce Jul 03 '13 at 08:11
  • Yes you can write library code using throws. The second you try to use any methods that throw a checked exception, there will need to be a matching catch. Have you tried throwing a checked exception in main? The code does not compile. It will only compile if you add throws to the main method, which is obviously very unusual. – James Jul 03 '13 at 08:29
-1

I agree that the Unchecked exceptions are checked part is really misleading. The better interpretation would be to divide all Java throwables into three categories:

  • Checked exceptions
  • Runtime exceptions
  • Errors

I personally prefer to think of Checked exceptions as something obligatory to catch in the code, and Runtime exceptions - as something optional to catch. You can process both (e.g. for logging), but you should try to recover just from the Checked ones.

Checked exceptions tend to introduce lots of redundant catch clauses. In some cases it could make sense to catch a Checked exception, wrap it in some Unchecked one and propagate it further.

Always keep in mind Item 41 from Effective Java: Avoid unnecessary use of checked exceptions. In other words, don't use checked exceptions for conditions from which the caller could not possibly recover, or for which the only foreseeable response would be for the program to exit.

Oleg Mikheev
  • 17,186
  • 14
  • 73
  • 95
  • "Checked exceptions introduce lots of redundant catch clauses." That's not true, in general. – Puce Jul 02 '13 at 22:53
  • @Puce - agreed. If there are lots of redundant catch clauses, that is a sign that the checked exceptions are not being dealt with in an optimal way ... or that there is a problem with the app / library / API design. – Stephen C Jul 02 '13 at 23:10