Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You don't need a list of 'bad' exceptions, you should treat everything as bad by default. Only catch what you can handle and recover from. CLR <a href="http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx" rel="nofollow noreferrer">can</a> <a href="http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx" rel="nofollow noreferrer">notify</a> you of unhandled exceptions so that you can log them appropriately. Swallowing everything but a black listed exceptions is not a proper way to fix your bugs. That would just mask them. Read <a href="http://msdn.microsoft.com/en-us/library/seyhszts.aspx" rel="nofollow noreferrer">this</a> and <a href="http://msdn.microsoft.com/en-us/library/2w8f0bss.aspx" rel="nofollow noreferrer">this</a>.</p> <blockquote> <p><strong>Do not exclude any special exceptions when catching for the purpose of transferring exceptions.</strong></p> <p>Instead of creating lists of special exceptions in your catch clauses, you should catch only those exceptions that you can legitimately handle. Exceptions that you cannot handle should not be treated as special cases in non-specific exception handlers. The following code example demonstrates incorrectly testing for special exceptions for the purposes of re-throwing them.</p> </blockquote> <pre><code>public class BadExceptionHandlingExample2 { public void DoWork() { // Do some work that might throw exceptions. } public void MethodWithBadHandler() { try { DoWork(); } catch (Exception e) { if (e is StackOverflowException || e is OutOfMemoryException) throw; // Handle the exception and // continue executing. } } } </code></pre> <p>Few other rules:</p> <blockquote> <p><strong>Avoid handling errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in application code. There are cases when handling errors in applications is acceptable, but such cases are rare.</strong></p> <p>An application should not handle exceptions that can result in an unexpected or exploitable state. If you cannot predict all possible causes of an exception and ensure that malicious code cannot exploit the resulting application state, you should allow the application to terminate instead of handling the exception.</p> <p><strong>Consider catching specific exceptions when you understand why it will be thrown in a given context.</strong></p> <p>You should catch only those exceptions that you can recover from. For example, a FileNotFoundException that results from an attempt to open a non-existent file can be handled by an application because it can communicate the problem to the user and allow the user to specify a different file name or create the file. A request to open a file that generates an ExecutionEngineException should not be handled because the underlying cause of the exception cannot be known with any degree of certainty, and the application cannot ensure that it is safe to continue executing.</p> </blockquote> <p><a href="http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx" rel="nofollow noreferrer">Eric Lippert</a> classifies all exceptions into 4 groups: Fatal, 'Boneheaded', Vexing, Exogenous. Following is my interpretation of Eric's advice:</p> <pre><code> Exc. type | What to do | Example ------------|-------------------------------------|------------------- Fatal | nothing, let CLR handle it | OutOfMemoryException ------------|-------------------------------------|------------------- Boneheaded | fix the bug that caused exception | ArgumentNullException ------------|-------------------------------------|------------------- Vexing | fix the bug that caused exception | FormatException from | (by catching exception because | Guid constructor | the framework provides no other way | (fixed in .NET 4.0 | way of handling). Open MS Connect | by Guid.TryParse) | issue. | ------------|-------------------------------------|------------------- Exogenous | handle exception programmatically | FileNotFoundException </code></pre> <p>This is roughly equivalent to <a href="http://rads.stackoverflow.com/amzn/click/0321545613" rel="nofollow noreferrer">Microsoft's </a> categorization: Usage, Program error and System failure. You can also use static analysis tools like <a href="https://stackoverflow.com/questions/2740738/fxcop-for-net-4-0">FxCop</a> to enforce <a href="http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/faq_3a00_-why-does-fxcop-warn-against-catch_2800_exception_29003f00_-_2d00_-part-1-_5b00_nick-guerrera_5d00_.aspx" rel="nofollow noreferrer">some</a> of these rules. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhich exceptions shouldn't I catch?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USDmitry
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhich exceptions shouldn't I catch?
      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. COYou can handle vexing exceptions as well. They are vexatious because you *must* handle them in most situations.
      singulars
      1. PO
      1. USEric Lippert
    2. CO@Eric: I've updated the answer with my interpretation of you article, hope I got it right.
      singulars
      1. PO
      1. USDmitry
    3. COLooks great! ___
      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