Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>What are some of the most common mistakes you've seen made when handling exceptions?</p> </blockquote> <p>I can think of lots. </p> <p>First read my article on categorization of exceptions into <em>vexing</em>, <em>boneheaded</em>, <em>fatal</em> and <em>exogenous</em>:</p> <p><a href="http://ericlippert.com/2008/09/10/vexing-exceptions/" rel="nofollow noreferrer">http://ericlippert.com/2008/09/10/vexing-exceptions/</a></p> <p>Some common errors:</p> <ul> <li>Failure to handle exogenous exceptions. </li> <li>Failure to handle vexing exceptions. </li> <li>Construction of methods that throw vexing exceptions. </li> <li>Handling exceptions that you actually cannot handle, like fatal exceptions. </li> <li><p>Handling exceptions that hide bugs in your code; don't handle a boneheaded exception, fix the bug so that it isn't thrown in the first place</p></li> <li><p>Security error: <strong>failure to the unsafe mode</strong></p> <pre><code>try { result = CheckPassword(); if (result == BadPassword) throw BadPasswordException(); } catch(BadPasswordException ex) { ReportError(ex); return; } catch(Exception ex) { LogException(ex); } AccessUserData(); </code></pre> <p>See what happened? We failed to the unsafe mode. If CheckPassword threw NetworkDriverIsAllMessedUpException then we caught it, logged it, and <em>accessed the user's data regardless of whether the password was correct</em>. Fail to the safe mode; when you get any exception, assume the worst.</p></li> <li><p>Security error: production of exceptions which <strong>leak sensitive information</strong>, directly or indirectly.</p> <p>This isn't exactly about handling exceptions in your code, it's about producing exceptions which are handled by hostile code.</p> <p>Funny story. Before .NET 1.0 shipped to customers we found a bug where it was possible to call a method that threw the exception "the assembly which called this method does not have permission to determine the name of file C:\foo.txt". Great. Thanks for letting me know. What is stopping said assembly from catching the exception and interrogating its message to get the file name? Nothing. We fixed that before we shipped. </p> <p>That's a direct problem. An indirect problem would be a problem I implemented in <code>LoadPicture</code>, in VBScript. It gave a different error message depending upon whether the incorrect argument is a directory, a file that isn't a picture, or a file that doesn't exist. Which means you could use it as a very slow disk browser! By trying a whole bunch of different things you could gradually build up a picture of what files and directories were on someone's hard disk. Exceptions should be designed so that if they are handled by untrustworthy code, that code learns none of the user's private information from whatever they did to cause the exception. (LoadPicture now gives much less helpful error messages.)</p></li> <li><p>Security and resource management error: Handlers which do not clean up resources are <strong>resource leaks</strong> waiting to happen. Resource leaks can be used as <strong>denial-of-service</strong> attacks by hostile partial trust code which deliberately creates exceptions-producing situations.</p></li> <li><p>Robustness error: Handlers must <strong>assume that program state is messed up</strong> unless handling a specific exogenous exception. This is particularly true of finally blocks. When you're handling an unexpected exception, it is entirely possible and even likely that something is deeply messed up in your program. You have no idea if any of your subsystems are working, and if they are, whether calling them will make the situation better or worse. Concentrate on logging the error and saving user data if possible and shut down as cleanly as you can. Assume that nothing works right.</p></li> <li><p>Security error: <strong>temporary global state mutations that have security impacts need to be undone</strong> <em>before</em> any code that might be hostile can run. Hostile code can run <em>before</em> finally blocks run! See my article on this for details:</p></li> </ul> <p><a href="http://blogs.msdn.com/ericlippert/archive/2004/09/01/224064.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/ericlippert/archive/2004/09/01/224064.aspx</a></p>
    singulars
    1. This table or related slice is empty.
    1. POCommon programming mistakes in .Net when handling exceptions?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USEric Lippert
    1. USEric Lippert
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCommon programming mistakes in .Net when handling exceptions?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhile one should only resume after an exception if one can "handle" it, there are many situations (such as when importing a "document" from a user-supplied file) where 99% of exceptions can be "properly handled" by discarding any partially-constructed objects and reporting that the operation failed. In a well-written application, an attempt to load something which is not a valid file shouldn't crash the application, but should simply fail. Some of the objects that were being built may have gotten corrupted, *but if they're discarded during stack unwinding, that shouldn't hurt anything*.
      singulars
      1. PO
      1. USsupercat
    2. COI wish .NET languages like C# and VB.NET would allow cleanup code to know the result of its associated `try`, without having to `catch` anything. If departure from normal program flow may have left an object in an invalid state, that may be a severe problem if the object, and no problem if it's going to be discarded. Rather than exceptions are by default unrecoverable, it would seem better to say that stack unwinding should expressly invalidate potentially-corrupt objects. That would allow recovery when it's safe but force shutdown when it's necessary.
      singulars
      1. PO
      1. USsupercat
    3. CO@supercat: That would be nice. CLR supports a `try-fault` block which is like a finally block that only is executed if there was an exception but it does not have the sort of cleanup semantics you describe. What I would like to see is an STM-like system that rolls back the state of a corrupted object in the event of an exception, but experiments thus far have shown that the performance cost is too high.
      singulars
      1. PO
      1. USEric Lippert
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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