Re: How to force the program to continue after unhandled exception detection

On Sat, 08 Mar 2008 00:33:58 -0800, nano2k <adrian.rotaru@xxxxxxxxxxx> wrote:

You're right, I made a mistake. I handled an event, that's right.
But the question remains. I want to get rid of exception helper and
let this event handler deal with the exception.

While I don't know what an "exception helper" is, and "deal with" is ambiguous. But assuming you mean for the event handler to actually trap the exception, the short answer is that you can't do that. It doesn't trap exceptions. It's entirely unrelated to the exception except that it gets raised by the .NET exception handler when an exception is thrown in the main GUI thread.

It's not an exception handler, and it will never be one.

I have tons of places where exception handling is necessary and the
handler looks like: "If an unhadled exception raises, than simply
display its message and continue running!". Why should I write _the
same_ code each time?

Because you want to handle the exception?

Of course, there are also many many cases where I need to handle
specific types of exceptions and take the appropriate measures. I'm
not talking about these ones.
But in modern exception handling approach, implementing a general
exception catching mechanism is a _must_.

Well, obviously it's not a "must" since plenty of modern frameworks that use exceptions don't provide a way to implement a general catching mechanism.

The only problem is that I get stucked in VSNET2005 when such an
"unhandled" exception occurs.

I'm not aware of any setting in VS2005 that will allow the debugger to ignore exceptions that would be handled by the .NET GUI thread exception handler. That doesn't mean the setting doesn't exist, it just means I don't know where it is if it does.

Regardless, it's not a good idea for you to have a dependency on this general purpose exception handling. Exceptions are exceptional cases. If they are being thrown regularly enough that you find it overly time-consuming to add exception handlers everywhere that they could come up, then either your code is throwing too many exceptions or you are not handling them in the way that you should.

An exception represents an error. Either you have a good way to recover from an error or you don't. If you do, then the exception handler that will allow you to recover from an error belongs with the code where the error is created. That means writing exception handling code (i.e. using try/catch). If you don't have a good way to recover from an error, then no matter where you put whatever code reacts to the error, it's still wrong.

I'm sorry your frustrated by this, but I believe that if what you're trying to do was a good way to design a program, you wouldn't be fighting the tools trying to do it.

Pete
.

Relevant Pages

  • Re: Exception management question...
    ... I suspect Form.Load is the result of receiving the WM_CREATE Win32 windows ... the exception in the Form Load event causes the ... they end up being handled by the Application.ThreadException event handler ... rather than the intended exception handler on the other form. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Try Finally...
    ... Now we can protect every more or less specialized action ... an error indication (exception or error code) has to be ... an according exception handler can be inserted into the code. ... resources, as they are related to specific actions. ...
    (comp.lang.pascal.delphi.misc)
  • Re: WinForms bug? ThreadException not invoked on Exceptions in system code pre-processing the me
    ... Message Queue and invoking the appropriate handler. ... if an Exception is raised during the PRE-PROCESSING of a Windows ... And because any handling will probably fail if there is no memory, the CLR will terminate the application without attempting to call the ApplicationException or UnhandledException events. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: BackgroungWork taske ended for no appearent reason
    ... To do the same thing with Try/Catch blocks requires wrapping every file access with a Do While ... ... If there was any exception thrown in your DoWork event handler, ... If the operation raises an exception that your code does not handle, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Frame-based exception handling problem on Server 2008
    ... In this case, the exception ends fatal, usually Cygwin creates a stack ... The Cygwin DLL is a POSIX ... handler is supposed to be *the* exception handler for Cygwin ... It also does not know if the signal handler returns or not. ...
    (microsoft.public.win32.programmer.kernel)