views:

252

answers:

4

Does .NET has an Exception that similar to Delphi's EAbort ?

Currently, define my own "AbortProcess" inheriting Exception. Together with My.Application.UnhandledException handler that ignoring "AbortProcess" I'm still wondering if similar mechanic in .NET is already exists.

Class AbortProcess
    Inherits System.Exception
End Class

Sub Abort()
    Throw New AbortProcess()
End Sub

Sub AppDomain_UnhandledException(ByVal sender As Object, ByVal e As ApplicationServices.UnhandledExceptionEventArgs)
    If TypeOf e.Exception Is AbortProcess Then
        e.ExitApplication = False
    End If
End Sub    

Sub PerformActions()
    Action1()
    If Not Action2() Then
        Abort()
    End If
    Action3()
    ...
End Sub

How does typical .NET developer handle this use case ?

A: 

The only one I know is ThreadAbortException which is "The exception that is thrown when a call is made to the Abort method."

FerranB
A: 

If you want to exit an application quickly in .Net an exception is not the best path. Any exception that you explicitly throw can be caught and swallowed. Even dangerous exceptions like ThreadAbortException can be caught if you do the right tricks.

The best way to exit an application quickly is to use Environment.Exit.

That or intentionally create a stack overflow scenario as it is an uncatchable exception when it is thrown by the CLR (providing no custom host).

JaredPar
As you'll note from the code example, this hypothetical exception is explicitly *not* meant to terminate the application. It's meant to abort the current event handler and go back to the message loop.
Rob Kennedy
A: 

This is basically exception that just serves as quick exit from function. .NET exceptions are not intended to do that and swallowing them is quite bad practice.

Exceptions should not be used for handling data flow. If you think that something could fail, you may throw exception, but then catch it at first appropriate moment. Letting exception to fall to UnhandledException function and swallowing it there is just bad practice that could leave your application in unknown state (since all methods through which exception goes will be "aborted").

In this case, if you need exception in that sub, I would catch it at a call:

try {
    PerformActions()
} catch (AbortProcess) {
    //do some cleaning up or just ignore
}

This way exception is caught close to it's origin and any clean-up is limited to that function only. All other exceptions will pass to your UnhandledException function where best thing you could do is to report an error and close application.

Josip Medved
+3  A: 

There are two qualities that define Delphi's EAbort exception class.

  1. The IDE comes pre-configured to not interrupt your program when it detects an exception of that class being raised.
  2. The main application exception handler recognizes EAbort and its descendants and does not display the usual message box when it catches such an exception.

It looks like the code you've proposed accomplishes the second part. You can configure Visual Studio for the first part; refer to the answer to another Stack Overflow question, Is there a better way to get Visual Studio to ignore try/catch in debug mode? I'm not aware of any exception class already designated for that.

The EAbort exception is meant to make the program stop running whatever event or message handler it's running and resume at the main message loop. In order for that to really work, though, all your other code needs to be written to handle exceptions properly. That is, they need to use finally sections to keep themselves in stable and consistent states, and they need to either rethrow or never catch exceptions that they aren't really capable of fixing.

Rob Kennedy
You are THE man. :)
Sake