Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Java Exceptions  RSS feed

 
James Luther
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers 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.

This is from the Java tutorials. https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
What does this mean?

How does one write code that throws only runtime exceptions. Must the code throw any exception at all
If the aim is simplicity then why not simply not specify any exceptions in the code
The whole subject of exceptions confuses me though so I must be muddled.
 
Stephan van Hulst
Saloon Keeper
Posts: 7803
142
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to CodeRanch, James!

Simplicity is indeed the aim. Exceptions actually help in that regard, believe it or not!

Back in the dark ages of programming, you would return a special value from your method to indicate that something went wrong. For instance, a method that reads a byte from a file might return 0 to 255 if it succeeds, but if something went wrong, it might return -1, or even -2 or -3 for different kinds of errors:

This gets confusing very quickly, because you have to look up what kind of error occurred when you get a value such as -2. Not just that, but what should a method return when its negative values actually indicate success?

It became clear that exceptional situations require exceptional values: exceptions! A method that reads a byte might now return a FileNotFoundException if a file doesn't exist, or an EOFException if the file has no more data, or an IOException if something else happened. It's much more clear what's going on.

A different problem arose: it was easy for programmers to forget to check for exceptions, and the exception made the entire program crash, even if it didn't have to. The designers of Java decided that there were two important types of exceptions: checked exceptions and unchecked exceptions. Checked exceptions are those that our program should be able to recover from, maybe by displaying an error message to the user, or trying to perform the action again at a later stage, or something else still. Unchecked exceptions are those that shouldn't be caught by our program, because they indicate that the programmer messed up somewhere, and they need to fix the program.

Java forces you to think about what to do with your checked exceptions. This may seem annoying at first, but it's actually really great, because it saves time later when your program crashes and you have to read through all the manuals to find out what went wrong.

The compiler knows something is a checked exception if it's a subclass of Exception, but NOT a subclass of RuntimeException. All other things are unchecked exceptions.
 
James Luther
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry I am curious about this. What happens if a method that's supposed to declare an exception ( checked or unchecked simply doesn't declare anyone). Eg you are advised to make your exceptions checked if they can be recovered from and unchecked if otherwise. What if you simply don't make any exceptions
 
Campbell Ritchie
Marshal
Posts: 55681
161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
RuntimeException and its subclasses occur entirely within the Java® runtime and are caused by programming errors and can only be sorted out by correcting the code.
Checked exceptions occur partially in the runtime and partially outside, and it is always possible to correct something

At least that is the theory. It shou‍ldn't take somebody experienced more than about 15″ to find all sorts of exceptions to those assertions.

Unchecked exceptions can occur unexpectedly. For example you might divide by 0 or forget to instantiate a field and a null pointer exception occurs 10000 lines of code away. So it would not be a good idea to declare unchecked exceptions. There would simply be too many of them, and a catch would be difficult to implement. There are some exceptions, e.g. this one, which can be avoided by judicious use of a loop. If you test for something and throw an unchecked exception, make sure to notify it with a tag in the documentation comments.
If an IOException occurs because there is a loose network cable, it is possible to reconnect the cable and try again. So they thought it would be a suitable example to be a checked exception. You declare it with a throws clause and all code using that method must either handle it or pass it on to other code to handle.

As I said, that is the theory. It is by no means 100% accurate. If you declare a checked Exception it is likely that it will be handled somewhere and your application can continue to run even if the exception is thrown.
 
Campbell Ritchie
Marshal
Posts: 55681
161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What will happen if you mistakenly pass null? You will suffer a null pointer exception, which that method cannot predict. As Stephan has told you, if anything goes wrong the simplest and neatest thing is to throw an exception. You can ignore the error codes he sowed on Monday, but you cannot ignore an exception. It will make it presence felt regardless.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!