6

I see that one definition can be this:

Generally RuntimeExceptions are exceptions that can be prevented programmatically.

But that is still not the definition of a checked exception. I thought checked exceptions were "exceptions that can be handled at compile-time". Is that correct and/or can you tell me more?

I also read this on the site, can you explain the quote?

Many people say that checked exceptions (i.e. these that you should explicitly catch or rethrow) should not be used at all.

Java: checked vs unchecked exception explanation

Can I just learn what the definition is? I also read somewhat unexpectedly:

NumberFormatException is unchecked`

But I would think that NumberFormatException is checked since I would handle that at compile-time. Can you please help me understand? I've done some Java programming but I never wrote my own exception class, why would I need that? enter image description here

Update

A definition is given is the SCJP book by Sierra / Bates:

enter image description here

Community
  • 1
  • 1
Niklas Rosencrantz
  • 25,640
  • 75
  • 229
  • 424
  • 1
    Take a look at this [graphic](http://www.oracleimg.com/technetwork/articles/entarch/javaexceptions-107916.jpg) (from: http://www.oracle.com/technetwork/articles/entarch/effective-exceptions-092345.html) and this [answer](http://stackoverflow.com/a/13104266/1393766). – Pshemo Apr 21 '13 at 14:30

3 Answers3

7

A checked exception is defined as any subclass of java.lang.Throwable (including Throwable itself) which is not a subclass of java.lang.Error or java.lang.RuntimeException. The guidelines you saw are just that, guidelines, designed to help you understand the intent of runtime exceptions.

See the Java Language Specification, section 11.1.1

The unchecked exception classes are the runtime exception classes and the error classes.

The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are all subclasses of Throwable other than RuntimeException and its subclasses and Error and its subclasses.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
Antimony
  • 37,781
  • 10
  • 100
  • 107
3

A more broad definition is:

CheckedExceptions are exceptions that you have to deal with explicitly. You either have to declare you can throw it or catch it and deal with it. Cunningham Wiki

As a result RuntimeExceptions are not checked, but NumberFormatException is checked if a method declares that it throws it and you are forced to catch or re-throw.

melbyts
  • 189
  • 1
  • 5
2

Checked exceptions allow you to verify at compile time that you are either handling exceptions or declaring them to be thrown.

Some do suggest avoiding checked exceptions. However, this does not eliminate the cost of managing exceptions. It shifts and magnifies it, from compile-time to run time and debug time.

From the Java tutorial:

[P]rogrammers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.

Unchecked exceptions allow you to not have to declare everywhere exceptions that can occur almost anywhere. From the Java tutorial:

Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).

NumberFormatException is unchecked because it falls within this camp. In many applications, number format exceptions can occur almost anywhere, and be numerous.

Andy Thomas
  • 84,978
  • 11
  • 107
  • 151
  • 2
    You can also get around exception checking by using a compiler plugin like Lomboc. – Antimony Apr 21 '13 at 15:42
  • 1
    The problem with the way Java implements checked exceptions is that it assumes any given type of exception will either always be thrown in situations where the caller can do something useful with it, or never be thrown in such cases. The reality is that most types of exceptions will sometimes be thrown in situations where the caller will be able to do something useful with them, and sometimes not. Alas, there's no concise syntax via which a caller can explicitly say "I am unprepared for checked exception XX; if it happens, throw it to my caller as an unchecked exception". – supercat Apr 22 '13 at 18:28
  • 1
    @supercat There is, however, a simple syntax to declare the *checked* exceptions which may be thrown to the caller. The utility to the caller/s is best left to the caller/s. – Andy Thomas Apr 22 '13 at 18:35
  • 1
    Checked exceptions could add improve expressiveness of the language if such a syntax existed and the framework were designed around it. Suppose, for example, that routine `ParseThing`, which is declared as `throws NumberFormatException`, calls some method which is declared as throwing that exception but is expected to always have valid inputs. If for some reason the inner routine *does* throws `NumberFormatException`, that should probably be rethrown as some type of `RuntimeError`, but there's no even-remotely-concise way to specify that. – supercat Apr 22 '13 at 18:42
  • 1
    @AndyThomas-Cramer: Right, so using normal white-spacing conventions a single method call (one line) becomes 4-8 lines of source code. Which is more likely--that people will bother including those 4-8 lines of source code to handle an exception they think will never happen, or that they'll ignore the exception and (wrongly) let it bubble up? – supercat Apr 22 '13 at 19:20
  • 1
    @supercat - I can't speak for 'people'. I personally find those short lines easy to write, easy to read -- and maximally local to the call. If you disagree, consider proposing a JSR. – Andy Thomas Apr 22 '13 at 19:35
  • 1
    @AndyThomas-Cramer: Given the frequency with which I've seen empty catch statements suggested by others as a proper way for a routine which doesn't `throws` anything to handle checked exceptions that its author doesn't think will ever get thrown [even though that only saves one statement versus throwing a new `RuntimeException`-derived exception], I suspect there's a lot more code written that will silently bubble up checked exceptions that really shouldn't, than code which bubbles them up because it's semantically the right thing to do. – supercat Apr 22 '13 at 19:41