Firstly - you should never try to "contain" errors; you should catch them where appropriate, handle them as necessary (even if that just means informing the user).
All "errors" in .NET are exposed through exceptions, so your catch(Exception ex) will catch all/any errors. However, you should probably be catching specific errors where possible - code littered with catch(Exception ex) is poorly designed. The "application needs to close" box is shown when an exception is unhandled by your code, i.e. when an exception is thrown outwith a try ... catch block OR when the catch isn't catching the correct exception. On Sat, Sep 4, 2010 at 5:18 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!
