Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h3>Short answer</h3> <ul> <li>Reflection is verbose by design</li> <li>Exception translation is idiomatic (catching lower level exception and abstracting it to a higher level) <ul> <li>... but don't overuse!</li> </ul></li> <li>Prefer custom exceptions to <code>java.lang.Exception</code>; it's probably <em>too</em> high of an abstraction</li> </ul> <hr> <h3>Point 1: Avoid reflection if at all possible</h3> <p>Here's a quote from <em>Effective Java 2nd Edition, Item 53: Prefer interfaces to reflection</em>:</p> <blockquote> <p>[The power of reflection], however, comes at a price:</p> <ul> <li>You lose all the benefits of compile time checking, including exception checking.</li> <li>The code required to perform reflective access is clumsy and verbose. It is tedious to write and difficult to read.</li> <li>Performance suffers. Reflective method invocation is much slower than normal method invocation.</li> </ul> <p>[...] As a rule, objects should not be accessed reflectively in normal application at runtime. There are a few sophisticated applications that require reflection. Examples include [omitted on purpose]. If you have any doubts to whether your application falls into one of these categories, it probably doesn't.</p> </blockquote> <hr> <h3>Point 2: Exception translation can be a good thing, but don't overuse</h3> <p>Here's a quote from <em>Effective Java 2nd Edition, Item 61: Throw exceptions appropriate to the abstraction</em>.</p> <blockquote> <p>It is disconcerting when a method throws an exception that has no apparent connection to the task that it performs. This often happens when a method propagates an exception thrown by a lower-level abstraction. [...]</p> <p>To avoid this problem, higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of higher-level abstraction. This idiom is known as <em>exception translation</em>.</p> <p>[...] While exception translation is superior to mindless propagation of exceptions from lower layers, it should not be overused. Where possible, the best way to deal with exceptions from lower layers is to avoid them, by ensuring that lower-level methods succeed. [...]</p> <p>If it is impossible to prevent exceptions from lower layers, the next best thing is to have the higher layer silently work around these exceptions, insulating the caller of the higher-level method from lower-level problems. Under these circumstances, it may be appropriate to log the exception using some appropriate logging facility. This allows an administrator to investigate the problem, while insulating client code and end user from it.</p> </blockquote> <hr> <h3>Point 3: <code>java.lang.Exception</code> is way too general</h3> <p>Looking at <a href="http://download.oracle.com/javase/6/docs/api/java/lang/Exception.html" rel="nofollow noreferrer">the documentation</a>, one can see a long list of direct known subclasses, with a wide-ranging topics from Reflection, RMI, XML parsing, I/O, GUI, cryptography, etc.</p> <p>Declaring that a method <code>throws Exception</code> is probably a poor API design decision, because it does not immediately tell the user anything useful about what <em>category</em> the exceptions may be, or under what circumstances they may be thrown. Contrast this with a hypothetical <code>ReflectionException</code>; this is a lot more informative, and it also allows user to catch specifically <code>ReflectionException</code> and not, say, an <code>IOException</code> that somehow slipped through.</p> <hr> <h3>Related questions</h3> <ul> <li><a href="https://stackoverflow.com/questions/986695/in-java-is-using-throws-exception-instead-of-throwing-mulitple-specific-exceptio"> In Java, is using <code>throws Exception</code> instead of throwing mulitple specific exceptions good practice? </a></li> <li><a href="https://stackoverflow.com/questions/480454/catching-several-exceptions-and-rethrowing-a-general-exception"> Catching several exceptions and rethrowing a general exception</a></li> <li><a href="https://stackoverflow.com/questions/237585/java-lang-exception-vs-rolling-your-own-exception"> <code>java.lang.Exception</code> vs. rolling your own exception </a></li> <li><a href="https://stackoverflow.com/questions/498217/when-should-throwable-be-used-instead-of-new-exception"> When should Throwable be used instead of new Exception? </a></li> <li><a href="https://stackoverflow.com/questions/1578557/need-authoritative-source-for-why-you-shouldnt-throw-or-catch-java-lang-exceptio">Need authoritative source for why you shouldn’t throw or catch java.lang.Exception</a></li> <li><a href="https://stackoverflow.com/questions/499437/in-java-when-should-i-create-a-checked-exception-and-when-should-it-be-a-runtim">In Java, when should I create a checked exception, and when should it be a runtime exception?</a></li> <li><a href="https://stackoverflow.com/questions/27578/when-to-choose-checked-and-unchecked-exceptions"> When to choose checked and unchecked exceptions </a></li> <li><a href="https://stackoverflow.com/questions/613954/the-case-against-checked-exceptions">The case against checked exceptions</a></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

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