title: .Net: Try...Catch paranoia - where does it end?
body: <p>I think I have something like "programmer's OCD". I like my code to be aesthetical and clean, and I want it to be "perfect" (as in handling all possible situations correctly and prettily). Often I find myself spending a lot of time just going over the same areas again and again to see where I can optimize and where I can fool-proof.</p>
  
  <p>So when it comes to try...catch blocks, I experience somewhat of a paranoia regarding what to enclose. I mean, where do I draw the line for what the code should cater to? Take file handling, for instance. Should I put, say, <i>every</i> damn file operation in a try...catch block, in case <i>something</i> could have happened (file being locked by someone/something external to the application, disk corruption etc)?</p>
  
  <p>Sometimes it burns my brain feeling that <i>maybe</i> there's <i>something</i> (that I'm not even aware of) that could trip up some piece of code..</p>
  
  <p><b>Edit:</b></p>
  
  <p>I'm not talking about using try...catch to cover shitty programming, I'm talking about when it comes to operations and procedures that are otherwise implemented properly, but rely on other factors outside of my control - even if they might be obscure (and this is the point) and only happen under extremely "unlucky" conditions that I haven't foreseen.</p>
  
  <p>File handling is kind of an obvious example. When I tend to get the jitters, it's when I'm wondering about what kind of processing goes on behind the scenes of otherwise built-in functionality, and how it responds to my code. </p>
  
  <p>Here's an example:</p>
  
  <pre><code>Dim serverUrl as String = My.Settings.ServerUrl
  </code></pre>
  
  <p>There's a disk operation involved there (reading from app.config). Should <i>that</i> be enclosed in a try...catch block? This is what I mean by where does it end.</p>
  
  <p>Fear of memory leaks is another thing. Is it only unmanaged code that poses a threat there? How do I know what is unmanaged code? Is there a list?</p>
  
  <p><b>More edit:</b></p>
  
  <p>Another area where I don't feel confident is when there are access restrictions or policies at play somewhere under the hood.</p>
  
  <p>When I read articles and discussions on programming, I see a lot of explanations along the lines of "well, your problem is that when you do a call to X, .Net is internally trying to access so-and-so, and unless your application is running in context type Y or you have privileges Z, it will throw an exception". Which just adds to my paranoia - when it comes to building water tight exception handling. Because I simply <i>don't know</i> all the inner workings of the language/platform, and don't know where to look (without having to devote my life to studying it).</p>
  
  <p><b>I would love for there to be some form of compendium or concise wiki for this <i>specifically</i>, that would outline which <i>areas</i> of programming that need special attention (file handling etc), with example scenarios, typical challenges and culprits (with solutions), best practice models, programming patterns and, not the least, provide a set of <i>guidelines</i> for mere mortals like me, that unfortunately weren't involved in actually constructing the language and its libraries.</b></p>
  
  <p>All this in <i>one place</i>, instead of having to track down scattered pieces of information in the language reference or random articles on the net - I don't even know what to look for, in many cases.</p>
  
  <p>As for my particular, current project, it's within the context of a Windows Service. There is no UI, and one of the subtasks I'm working on is to create a robust bootstrapper that handles all problem scenarios gracefully. In this case, it's all about logging - and then either ignoring the exception (if it's trivial enough) - or simply exit! If the problem happens <i>while attempting to log</i> - then what do I do? Just quit - with no trace of what happened? This bootstrapper only logs its startup (after that, the main assembly - which is dynamically loaded - takes over and logs its own stuff, albeit with the same challenges), and does so to a simple "bootstrap.log" file. Would it be better (or a worthwile addition) to  have it log to the EventLog? Or is the EventLog another area that could spawn a new world of problems (again, access restrictions etc. Does the EventLog <i>also</i> base itself on disk operations that would need to be "tried and caught"..?)</p>
  
  <p>See? Paranoia.</p>