StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<ol> <li><p>Is the above consider a checked exception? No The fact that you are handling an exception does not make it a Checked Exception if it is a RuntimeException.</p></li> <li><p>Is RuntimeException an unchecked exception? Yes</p></li> </ol> <p>Checked Exceptions are subclasses of java.lang.Exception Unchecked Exceptions are subclasses of java.lang.RuntimeException</p> <p>Calls throwing checked exceptions need to be enclosed in a try{} block or handled in a level above in the caller of the method. In that case the current method must declare that it throws said exceptions so that the callers can make appropriate arrangements to handle the exception.</p> <p>Hope this helps.</p> <blockquote> <p>Q: should I bubble up the exact exception or mask it using Exception?</p> </blockquote> <p>A: Yes this is a very good question and important design consideration. The class Exception is a very general exception class and can be used to wrap internal low level exceptions. You would better create a custom exception and wrap inside it. But, and a big one - Never ever obscure in underlying original root cause. For ex, <code>Dont ever</code> do following - </p> <pre><code>try { attemptLogin(userCredentials); } catch (SQLException sqle) { throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem. } </code></pre> <p>Instead do following:</p> <pre><code>try { attemptLogin(userCredentials); } catch (SQLException sqle) { throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!. } </code></pre> <p>Eating away original root cause buries the actual cause beyond recovery is a nightmare for production support teams where all they are given access to is application logs and error messages. Although the latter is a better design but many people dont use it often because developers just fail to pass on the underlying message to caller. So make a firm note: <code>Always pass on the actual exception</code> back whether or not wrapped in any application specific exception.</p> <blockquote> <p>On try-catching RuntimeExceptions</p> </blockquote> <p>RuntimeExceptions as a general rule should not be try-catched. They generally signal a programming error and should be left alone. Instead the programmer should check the error condition before invoking some code which might result in a RuntimeException. For ex:</p> <pre><code>try { setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!); } catch (NullPointerException npe) { sendError("Sorry, your userObject was null. Please contact customer care."); } </code></pre> <p>This is a bad programming practice. Instead a null-check should have been done like - </p> <pre><code>if (userObject != null) { setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!); } else { sendError("Sorry, your userObject was null. Please contact customer care."); } </code></pre> <p>But there are times when such error checking is expensive such as number formatting, consider this - </p> <pre><code>try { String userAge = (String)request.getParameter("age"); userObject.setAge(Integer.parseInt(strUserAge)); } catch (NumberFormatException npe) { sendError("Sorry, Age is supposed to be an Integer. Please try again."); } </code></pre> <p>Here pre-invocation error checking is not worth the effort because it essentially means to duplicate all the string-to-integer conversion code inside parseInt() method - and is error prone if implemented by a developer. So it is better to just do away with try-catch. </p> <p>So NullPointerException and NumberFormatException are both RuntimeExceptions, catching a NullPointerException should replaced with a graceful null-check while I recommend catching a NumberFormatException explicitly to avoid possible introduction of error prone code.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload