Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Exception handling is difficult in any application. You need to think about each and every exception and quickly get into a pattern that works for you. I try and group exceptions into one of the following categories...</p> <ul> <li><strong>Exceptions that should only happen if your code is wrong (or you don't understand, or you don't have control over them):</strong></li> </ul> <p><strong>Example:</strong> Maybe your persistence framework requires you to catch SQL exceptions that could arise from malformed SQL, however, you're executing a hard coded query.</p> <p><strong>Handling:</strong> In my experience most exceptions fall in this category. At the very least, log them. Even better, send them to an exception handling service which logs them. Then in the future if you decide you want to log them differently or do something differently with them you can change it in one place. Maybe you also want to send a flag up to the UI layer saying that some kind of error occurred and they should retry their operation. Maybe you mail an administrator.</p> <p>You will also need to return something to the higher layers so that life on the server goes on. Maybe this is a default value, or maybe this is null. Maybe you have some way of canceling the entire operation.</p> <p>Another choice is to give the exception handling service two handling methods. A <code>handleUnexpectedException()</code> method would notify the user but not rethrow an exception and you could then return a default value if you have the ability to unwind the stack yourself or continue on in some way. A <code>handleFatalException()</code> method would notify the user and rethrow some kind of exception so that you can let the exception throwing unwind the stack for you.</p> <ul> <li><strong>Exceptions that are actually caused by the user:</strong></li> </ul> <p><strong>Example:</strong> The user is trying to update a foobar widget and give it a new name, but a foobar widget already exists with the name they want.</p> <p><strong>Handling:</strong> In this case you need to get the exception back to the user. In this case you can go ahead and keep throwing the exception (or better, don't even catch it) until it reaches the UI layer and then the UI layer should know how to handle the exception. Make sure to document these exceptions so that you (or whomever is writing your UI) is aware that they exist and knows to expect them.</p> <ul> <li><strong>Exceptions that you can actually handle:</strong></li> </ul> <p><strong>Example:</strong> You make a remote service call and the remote service times out but you know they have a history of doing so and you should just redo the call.</p> <p><strong>Handling:</strong> Sometimes these exceptions start off in the first category. After your application has been in the wild for a while you realize that you actually have a good way to handle it. Sometimes, like with exceptions from optimistic locking or interrupted exceptions, catching the exception and doing something with it is just a part of business. In these cases, handle the exception. If you're language (I'm thinking Java) distinguishes between checked and unchecked exceptions I would recommend these always be checked exceptions.</p> <p>To address your above question I would delegate the initial exception to a service that would notify the user and depending on what kind of object MyObj is (e.g. settings) I might let this be a non-fatal exception and return a default value or if I can't do that (e.g. user account) then I might let this be a fatal exception so I don't have to worry about it.</p>
    singulars
    1. This table or related slice is empty.
    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. 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.
    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