Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Obviously you incur in the penalty of creating new objects (the new Exception) so, exactly as you do with every line of code that you append to your program, you must to decide if the better categorization of exceptions pays for the extra work. </p> <p>As a piece of advice to make that decision, if your new objects are not carrying extra information about the exception then you can forget constructing new exceptions. </p> <p>However, in other circumstances, having a hierarchy of exceptions is very convenient for the user of your classes. Suppose you're implementing the Facade pattern neither of the so far considered scenarios is good:</p> <ol> <li>is not good that you raise every exception as an Exception object because you're losing (probably) valuable information</li> <li>is not good neither to raise every kind of object that you catch because doing so you're failing in creating the facade</li> </ol> <p>In this hypothetical case, the better thing to do is to create a hierarchy of exception classes that, abstracting your users from the inner complexities of the system, allows them to know something about the kind of exception produced. </p> <p>As a side note: </p> <p>I personally dislike the use of exceptions (hierarchies of classes derived from the Exception class) to implement logic. Like in the case:</p> <pre><code>try { // something that will raise an exception almost half the time } catch( InsufficientFunds e) { // Inform the customer is broke } catch( UnknownAccount e ) { // Ask for a new account number } </code></pre>
 

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