Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Suppress-catch or throw exceptions which can never occur?

Say I have the following line in a method:

 String encodedString = URLEncoder.encode(foo, "utf-8");

this method throws an UnsupportedEncodingException. Which is better:

/** @throws UnsupportedEncodingException umm...never
 */
public void myMethod() throws UnsupportedEncodingException {
   ...
   String encodedString = URLEncoder.encode(foo, "utf-8");
   ...
}

(forcing the caller to catch this himself) Or:

public void myMethod() {
   try {
     ...
     String encodedString = URLEncoder.encode(foo, "utf-8");
     ...
   catch(UnsupportedEncodingException e) {
      Logger.log("cosmic ray detected!");
   }

}

Or is there a more elegant way of handling exceptions which can't really ever occur?

like image 570
Epaga Avatar asked Mar 10 '10 09:03

Epaga


People also ask

Which exceptions are suppressed when the given program runs and throws an exception?

In short, a suppressed exception is an exception that is thrown but somehow ignored. A common scenario for this in Java is when the finally block throws an exception. Any exception originally thrown in the try block is then suppressed.

In which of the following An exception error can occur?

Following are some scenarios where an exception occurs. A user has entered an invalid data. A file that needs to be opened cannot be found. A network connection has been lost in the middle of communications or the JVM has run out of memory.

Do not suppress or ignore checked exceptions?

Programmers often suppress checked exceptions by catching exceptions with an empty or trivial catch block. Each catch block must ensure that the program continues only with valid invariants.

Can we handle exception without catch block?

throws: The throws keyword is used for exception handling without try & catch block. It specifies the exceptions that a method can throw to the caller and does not handle itself.


2 Answers

Never say never ;)

In the example above you could always catch the exception then throw a RuntimeException:

public void myMethod() {
   try {
      ...
      String encodedString = URLEncoder.encode(foo, "utf-8");
       ...
   } catch(UnsupportedEncodingException e) {
     throw new RuntimeException("This should not be possible",e);
   }

}

That way the caller isn't forced to catch something you 99.999% sure will never happen, but in the crazy event that it does happen you still get an exception bubble up to a point where you'll hopefully notice it and be able to quickly realize what's changed and fix it.

HTH

like image 68
simonlord Avatar answered Oct 06 '22 00:10

simonlord


If you can pretty much guarantee that the exception can never occur, then it's better to localize this assertion at the narrowest scope rather than letting it propagate, because other people may not realize that this is the case without looking at documentations.

If a method is declared to throw something, then there should be scenarios where it actually does. If it's pretty much guaranteed to never does, then it's better to omit the throws clause altogether and simplify your API.

You should always throw exceptions appropriate to your level of abstraction (Effective Java 2nd Edition, item 61). Declaring that you might throw something, when it's guaranteed never to occur, breaks this design guideline.

like image 32
polygenelubricants Avatar answered Oct 06 '22 01:10

polygenelubricants