Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If your application is primarily going to be used by other clients and is not standalone, it generally makes sense to throw exceptions if a condition arises that you don't know how to (or don't want to) handle, and there's no sensible way for you to recover from it. Clients should be able to decide how they want to handle any exceptions that you might throw.</p> <p>On the other hand, if your application <em>is</em> the endpoint, throwing an exception essentially becomes a notification mechanism to alert people that something has gone terribly wrong. In such cases, you need to consider a few things:</p> <ul> <li><p><strong>How important is the continued running of the application? Is this error really unrecoverable?</strong> Throwing an exception and terminating your program is not something you want to be doing on the space shuttle.</p></li> <li><p><strong>Are you using exceptions as a proxy for real logging?</strong> There's almost never a reason to do this; consider a real logging mechanism instead. Catch the exception and have the logger work out what happened.</p></li> <li><p><strong>What are you trying to convey by throwing the exception yourself?</strong> Ask yourself what the value in throwing a new exception is, and consider carefully whether there isn't a better way to do what you want.</p></li> <li><p><strong>Not catching an exception may leave resources in a bad state.</strong> If you don't gracefully exit, things are generally not cleaned up for you. Make sure you understand what you're doing if you need to do this -- and if you're not going to catch it, at least consider a <code>try-finally</code> block so you can do some tidying up.</p></li> </ul>
 

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