Try/Catch blocks are not intended to stifle or suffocate the innocent little exception so that its existence will remain unsung. Their primary use is to allow developers to *gracefully* handle all possible error conditions. You must understand that when an exception is raised by code, it will cause the control to skip to the next available catch block. Even if you have Try/Catch blocks in all methods, the control would still have skipped some (probably) essential code. This will then cause the calling code to fail at some step.
An analogy that comes to my (imaginative) mind is a factory where a product is passed from one processing unit to another on a conveyor belt. Let's say that one of the units in the sequence malfunctions in such a way to introduce an almost imperceptible flaw into the object. The object passes to other units along the line and comes out complete. But would you expect the completed product to be perfect ? Therefore, I have two suggestions: 1. Run your app in debug mode until you encounter the error. 2. Don't let your exceptions die a silent death in an obscure location. Make sure to provide diagnostic logging in all Catch blocks which write out the Stack trace. On Sep 3, 8:53 pm, Julie <[email protected]> wrote: > Hi, I have an application built with C# (Visual Studio 2005) whose > Release version runs on a target machine. The application typically > runs without crashing, but on occasion crashes. > The application is multi-threaded, and I specifically put try/catch > statements around the code in each of these threads, hoping to contain > the crash. But I guess that wasn't sufficient, as the app crashed > yesterday. The error that comes up is simply "NameOfApp needs to > close" (or something like that). No indication of where in the code > the crash occurred. > > Would this most likely be some operating system-level crash, or what > do you think? What does the fact that the error shows no source code > location information tell us about this error? > > Also, I am trying to understand what types of errors try/catch is > capable of catching, and what it is not. It seems I can catch many > different types of errors, much more so than when I used to work on > Visual C++ 6.0. > > Thanks!
