0

I am working on a Windows Forms project and a Class Library project in Visual Studio 2012.

If you have 1 or more fatal runtime exceptions which .NET exception would you use as its base? I know ApplicationException is used for non-fatal application exception. But I dont see which one .NET recommends for fatal application exception.

Or would you define you own base exception for fatal runtime exceptions? If yes then from which .NET exception you would derive it?

Thanks

ChumboChappati
  • 1,442
  • 4
  • 18
  • 38
  • 1
    It really depends on what you mean by a fatal exception. Any exception can be fatal if it's not handled... That said, if you're creating new exceptions because none of the existing specific ones are suitable, these days you may as well just [inherit from Exception](http://stackoverflow.com/a/5685937/791010) - `ApplicationException` is a holdover from days of yore. – James Thorpe Oct 22 '15 at 14:44
  • Thanks for the link. So `ApplicationException` is basically useless and recommended approach is to have your own base exceptions (one for fatal and one for non-fatal) derived from `Exception`. Can you make your remark an answer so I can accept it? – ChumboChappati Oct 22 '15 at 14:51
  • If you want to differentiate between "fatal" and "non-fatal", then yes. But as I said, any exception can be fatal if it's not caught. – James Thorpe Oct 22 '15 at 14:51
  • yes I have to differentiate between "fatal" and "non-fatal" in this application. – ChumboChappati Oct 22 '15 at 14:53
  • What kinds of things are "fatal exceptions" that aren't thrown by the runtime? – D Stanley Oct 22 '15 at 14:55
  • You'll have to use Environment.FailFast() to make code fatal. Just throw a plain Exception object to make it obvious that it shouldn't be caught and only reported. – Hans Passant Oct 22 '15 at 14:56
  • I think what James is trying to relay is that even if you differentiate two exceptions, like `FatalException` and `NonFatalException`, even `NonFatalException` could result in the application terminating if the exception is not caught and handled. I'd avoid rolling your own exception system and just let the application throw and catch the built-in exceptions or custom exceptions if necessary, and let the calling code decide to handle it (non-fatal) or punt (fatal). – Ron Beyer Oct 22 '15 at 14:58
  • By the way as far as I know there are only two "fatal" exceptions as of C#5, `StackOverflowException` and `AccessViolationException`, neither of which can be caught and are truly fatal exceptions. From what I can find, the runtime terminates when it encounters those exceptions, its not something that is coded in (since it will skip catch blocks and terminate). – Ron Beyer Oct 22 '15 at 15:01
  • For example in config file there is a config value which has to be set; if its not set then it would be term as "fatal" application exception and the application will terminate. – ChumboChappati Oct 22 '15 at 15:16
  • 2
    @ChumboChappati In that case I would create a `MissingConfigurationValueException` and let the calling code determine how to handle it (message/log/termination) etc. You don't need to qualify it as fatal or non-fatal, its up to the caller to decide. – Ron Beyer Oct 22 '15 at 15:18

0 Answers0