Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Wrapping <em>any</em> piece of code in a <code>try</code>/<code>catch</code> block without a good reason is bad practice.</strong> </p> <p>In the .NET programming model, exceptions should be reserved for truly exceptional cases or conditions. You should <em>only</em> try to catch exceptions that you can actually <em>do something</em> about. Furthermore, you should should hardly <em>ever</em> catch the base <code>System.Exception</code> class (but rather prefer to catch the more specific, derived exception classes you <em>can</em> handle). And should a truly unexpected exception be encountered during the course of your program's execution, you actually <em>should</em> crash.</p> <p>Obviously the "correct" answer would have to be made on a case-by-case basis, depending on what's going on inside that <code>// code</code> placeholder in your <code>catch</code> block. But if you're asking for a general rule or "best practice", you should always have a specific reason to catch exceptions, not just wrap all of your code in a giant <code>try</code>/<code>catch</code> block as a matter of course without thinking about it.</p> <p>Note that if you're simply trying to catch any unhandled exceptions that might occur for the purposes of logging or error reporting, you should be using the <a href="http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx" rel="nofollow noreferrer"><code>AppDomain.UnhandledException</code> event</a>. This is a notification-only event, so it doesn't allow you to <em>handle</em> those exceptions, but it is the right place to implement your logging or error reporting functionality after your application has crashed.</p> <hr> <p><strong>EDIT:</strong> As I was catching up on my reading of Raymond Chen's excellent blog, <a href="http://blogs.msdn.com/b/oldnewthing/" rel="nofollow noreferrer">"The Old New Thing"</a>, I noticed that he had recently published an article on a similar topic. It's specific to COM, rather than the .NET Framework, but the general concepts regarding error handling are equally applicable to both environments. I thought I'd share a couple of gems from the article here, in support of my [apparently quite controversial] opinion.</p> <blockquote> <p>Historically, COM placed a giant try/except around your server's methods. If your server encountered what would normally be an unhandled exception, the giant try/except would catch it and turn it into the error <code>RPC_E_SERVERFAULT</code>. It then marked the exception as handled, so that the server remained running, thereby "improving robustness by keeping the server running even when it encountered a problem."</p> <p>Mind you, this was actually a disservice.</p> <p>The fact that an unhandled exception occurred means that the server was in an unexpected state. By catching the exception and saying, "Don't worry, it's all good," you end up leaving a corrupted server running.</p> <p>[ . . . ]</p> <p>Catching all exceptions and letting the process continue running assumes that a server can recover from an unexpected failure. But this is absurd. You already know that the server is unrecoverably toast: It crashed!</p> <p>Much better is to let the server crash so that the crash dump can be captured at the point of the failure. Now you have a fighting chance of figuring out what's going on.</p> </blockquote> <p>You can [and should] read the whole article here on his blog: <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/01/20/10117963.aspx" rel="nofollow noreferrer">How to turn off the exception handler that COM "helpfully" wraps around your server</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. POMain method code entirely inside try/catch: Is it bad practice?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBill
    1. USCody Gray
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMain method code entirely inside try/catch: Is it bad practice?
      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. VTDownMod
    1. CO@gridzbi: Okay? So do it in the `AppDomain.UnhandledException` event. That's what it's *designed* for. Wrapping your code in a try/catch block is a generally *bad* idea, especially for something like this. A truly unhandled exception that you can't do anything about **should** cause your application to crash. Logging is a secondary concern, and a provision has been made for it.
      singulars
      1. PO
      1. USCody Gray
    2. CONever say "never". There are loads of cases where you have to catch System.Exception. E.g., if you're processing an arbitrary plugin call, which may throw anything, but you shoud kill it gracefully if anything fails. Or if you're interpreting an arbitrary code entered by a user, which may throw absolutely anything - in this case you have to show a stack trace to a user and return back to repl.
      singulars
      1. PO
      1. USSK-logic
    3. CO@SK-logic: I'm not familiar with instances where the user can raise their own exceptions. And yes, I suppose there might be 3rd party libraries who get things wrong and raise `System.Exception`, but that's still no excuse for swallowing *all* of your code with a try/catch block. Mind you, the rest of my answer is pretty relenting about having to decide this on a case-by-case basis; the way I perceive the original question is as one of "best practice", not "is this ever conceivably justified?"
      singulars
      1. PO
      1. USCody Gray
 

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