• Post Reply Bookmark Topic Watch Topic
  • New Topic

Understanding checked exceptions  RSS feed

 
Ranch Hand
Posts: 115
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having a hard time understanding checked exceptions and unchecked expressions in the sense that checked expressions must be handled . Does that mean that if i use a library method that throws a type of exceptions that is a checked exception i must catch it in the next caller method or throw it to the next caller method down the stack ? How do i know that a library method can throw a checked exception ? Will it simply not compile if i use a method that can throw checked exceptions without throwing it further or handle it in the caller method ? What if i want to write the method myself . to create the same scenario i just need to have a statement like throw new <type of exception that is a checked exception >("a string") ; ? Also the initial method that throws the exception must have a throws statement in the method header as well or actually handle it itself using a try /catch block ?

Also checked exceptions can only be thrown by the programmer's code and never by the Java virtual machine ?

Thanks
 
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tiberius Marius wrote:I am having a hard time understanding checked exceptions and unchecked expressions in the sense that checked expressions must be handled . Does that mean that if i use a library method that throws a type of exceptions that is a checked exception i must catch it in the next caller method or throw it to the next caller method down the stack ?


Yes. Your method must catch and handle checked exceptions that can be encountered, *or* your method must declare that it too can throw checked exceptions.

Tiberius Marius wrote:How do i know that a library method can throw a checked exception ? Will it simply not compile if i use a method that can throw checked exceptions without throwing it further or handle it in the caller method ?


The documentation is a good place to see if a checked exception will be thrown. And yes, the compiler will complain about it too.

Tiberius Marius wrote: What if i want to write the method myself . to create the same scenario i just need to have a statement like throw new <type of exception that is a checked exception >("a string") ; ? Also the initial method that throws the exception must have a throws statement in the method header as well or actually handle it itself using a try /catch block ?


To create a method that throws a check exception, your method must declare that it throws the exception. And of course, it must actually throw that exception -- whether it creates one and throws it, or simply not catch one that is encountered doesn't really matter.

Henry
 
Marshal
Posts: 4053
239
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tiberius Marius wrote:Does that mean that if i use a library method that throws a type of exceptions that is a checked exception i must catch it in the next caller method or throw it to the next caller method down the stack ?

Exactly right.
Tiberius Marius wrote:How do i know that a library method can throw a checked exception ? Will it simply not compile if i use a method that can throw checked exceptions without throwing it further or handle it in the caller method ?

Correct, it will not compile. Also the method throwing the Checked Exception must declare it in its signature, for example

Tiberius Marius wrote:What if i want to write the method myself . to create the same scenario i just need to have a statement like throw new <type of exception that is a checked exception >("a string") ; ?

Correct, just like in my previous example.
Tiberius Marius wrote:Also the initial method that throws the exception must have a throws statement in the method header as well or actually handle it itself using a try /catch block ?

Yes, again like my example. Not quite sure what you're asking in the second part of this question but if you have a method body that deals with some Exception with a try catch but does not ever throw that Exception out of the method then you do not need to declare it in the method signature.
 
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Start by going through the Java Tutorials.
 
Tiberius Marius
Ranch Hand
Posts: 115
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks both Tim and Henry for the clarifications . I suspect my last statement is correct as well , i mean checked exceptions can only be thrown by the programmer's code and never by the Java virtual machine whereas unchecked exceptions can be thrown by the java virtual machine as well.
 
Campbell Ritchie
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tiberius Marius wrote: . . . I suspect my last statement is correct as well , i mean checked exceptions can only be thrown by the programmer's code and never by the Java virtual machine . . .
That looks at best dubious.

If the wire connecting you to the Internet is pulled out while you are loading a file, you may suffer an IOException, which is checked. I am not sure whether that Exception is thrown by the JVM, or by code specifically written in the Socket class, BufferedReader class or whatever, or by the operating system.
 
Tiberius Marius
Ranch Hand
Posts: 115
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Tiberius Marius wrote: . . . I suspect my last statement is correct as well , i mean checked exceptions can only be thrown by the programmer's code and never by the Java virtual machine . . .
That looks at best dubious.

If the wire connecting you to the Internet is pulled out while you are loading a file, you may suffer an IOException, which is checked. I am not sure whether that Exception is thrown by the JVM, or by code specifically written in the Socket class, BufferedReader class or whatever, or by the operating system.


Yes , ClassNotFoundException is a checked exception and its thrown when a class is not found .
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tiberius Marius wrote:Also checked exceptions can only be thrown by the programmer's code and never by the Java virtual machine ?

I think Tim, Henry and Campbell have covered most of it, but I'd suggest that you're worrying a bit too much about the mechanics of the process, when what you should probably concentrate on is when checked exceptions are thrown (in design terms, not execution) and why you might choose to throw one. And for that, the tutorials are probably the place to start.

Personally, I've always liked the idea of checked exceptions, but the practise often falls short of the mark. Specifically, I think making IOException checked was a mistake since, in most cases, a program can't recover from one (and hence, I suspect, the reason for the appearance of "try with resources"). The trouble is that it has a pile of subclasses that probably do qualify as checked exceptions.

HIH

Winston
 
Campbell Ritchie
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The theory was there are exceptions which occur entirely within the runtime (runtime exceptions) and those which occur partially in the runtime and partially outwith it (checked exceptions).
The trouble is, there are so many exceptions to all rules about exceptions and that is no exception in that is has exceptions.

Winston has shown us that IOException might well be unchecked because it is often impossible to recover from. But I cannot remember ever suffering an IOException. Its subclasses like FileNotFoundException occur often enough, but not IOException itself.
A long time ago somebody pointed out to me that some runtime exceptions might be recoverable from, e.g. NumberFormatException.
So there is the theory but the practice turns out to be rather different.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Its subclasses like FileNotFoundException occur often enough, but not IOException itself.

Not to mention the fact that there is IOError, which is not checked, which would seem to make IOException redundant. Unfortunately, it only appeared in version 6.
I suspect that the original idea was to make IOException a blanket superclass that covers all the myriad possibilities for a genuine checked exception, but in that case, why didn't they just make it abstract?

Too late now...

Winston
 
Campbell Ritchie
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There were all sorts of errors made in the early days of Java® which you can't correct now.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!