3

I need to create a fatal exception on demand, using C#. While I have done this unintentionally enough times, now I need to, I can't find a simple way.

It's easy enough to cause a null reference error or divide by zero etc., but I need something which will CTD without giving the option to continue.

Thanks for your help.

Panjo
  • 63
  • 1
  • 6
  • 6
    Shouldn't an unhandled `throw new Exception("Intentional error");` be enough? – Lennart Oct 17 '14 at 10:49
  • 1
    I don't understand. What is `CTD`? – Soner Gönül Oct 17 '14 at 10:49
  • 1
    Crash to Desktop @SonerGönül – Lennart Oct 17 '14 at 10:49
  • 4
    Keep your eyes on the ball, you're interested in the end result, not the way to get there. Just call Environment.FailFast(). – Hans Passant Oct 17 '14 at 10:52
  • Interesting, didn't know about that! @HansPassant – Lennart Oct 17 '14 at 11:02
  • @HansPassant Me neither, post it as an answer! – helb Oct 17 '14 at 11:04
  • Thanks all - and thanks @HansPassant, that worked brilliantly (I will accept if you post as an answer). – Panjo Oct 17 '14 at 11:08
  • @CodeCaster I disagree this is a duplicate of the question presented - plus this answer is more useful. – Panjo Oct 17 '14 at 11:09
  • I close-voted because [that question](http://stackoverflow.com/questions/11591023/is-there-a-setting-that-is-preventing-the-unhandled-exception-dialog-from-displa) answers your implicit question _"Why does it give the option to continue?"_. When you follow the advice in that answer, you won't get the option to continue. If Hans wants to, he can reopen this one and answer it, but I think he'd better update his answer there, to maintain all information about this kind of exception throwing and handling in one place. – CodeCaster Oct 17 '14 at 11:12

2 Answers2

10

Don't use an exception to accomplish this, it has too many side-effects. Including not terminating the program at all, whether an unhandled exception ends the program is a CLR policy that can be changed. Both by a custom CLR host and still exposed today by the legacyUnhandledExceptionPolicy config attribute.

The most reliable way to instantly abort a program, without any events getting fired and without any cleanup (including not running finalizers) is Environment.FailFast().

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • This crashes my Test Explorer in Visual Studio 2013 though; "vstest.executionengine.clr20.exe has stopped working" and "The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information. If the logs are not enabled, then enable the logs and try again.". The exception in this case seems milder. – Ruud van Gaal May 11 '17 at 15:45
0

IMHO I prefer a milder approach. I create a custom Exception that I call FatalException. https://learn.microsoft.com/en-us/dotnet/standard/exceptions/how-to-create-user-defined-exceptions. That way when I call methods that throw FatalException, I simply do a try-catch around the call and catch (FatalException fe). I usually re-throw as necessary to get back to parent form which also has a the final catch for the FatalException exception and then log it (I use Log4Net), show a messagebox as to the reason for the Fatal situation and call my overridden Dispose() method and exit the application gracefully. Obviously this becomes more difficult the deeper your nested calls. The extra work is worth the extra grace to me. If this becomes a standard in your application, you will understand it when you encounter it and ensure that you don't break it. I put my Custom Exceptions in a DLL library. If your code is in a library, this approach still works because the Exceptions are also in a library they can be shared by both another library and the main application. This means your library can throw a FatalException as well, although the reasons for doing so should be few a far between.

Al C.
  • 1
  • 1