Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This depends on the application and the situation. If your building a library component, you should bubble up exceptions, although they should be wrapped to be contextual with your component. For example if your building an Xml Database and let's say you are using the file system to store your data, and you are using file system permissions to secure the data. You wouldn't want to bubble up a FileIOAccessDenied exception as that leaks your implementation. Instead you would wrap the exception and throw an AccessDenied error. This is especially true if you distribute the component to third parties.</p> <p>As for if it's okay to swallow exceptions. That depends on your system. If your application can handle the failure cases and there is no benefit from notifying the user why it failed then go ahead, although I highly recommend that your log the failure. I've always found it frustating being called to help troubleshoot an issue and find they were swallowing the exception (or replacing it and throwing a new one instead without setting the inner exception).</p> <p>In general I use the following rules:</p> <ol> <li>In my components &amp; libraries I only catch an exception if I intend to handle it or do something based on it. Or if I want to provide additional contextual information in an exception.</li> <li>I use a general try catch at the application entry point, or the highest level possible. If an exception gets here I just log it and let it fail. Ideally exceptions should never get here. </li> </ol> <p>I find the following code to be a smell:</p> <pre><code>try { //do something } catch(Exception) { throw; } </code></pre> <p>Code like this serves no point and should not be included. </p>
 

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