I would like to differentiate between exceptions coming from business logic like

  • requested database record does not exist
  • attempt to store invalid business data (validation failed)
  • provided CSV file has wrong format

from standard system exceptions like

  • database connection timeout
  • file I/O error
  • out of memory

I generate business logic exceptions in my code as a quick way to quit undergoing operation when something goes wrong (instead of returning false and other techniques).

So I would implement different handling of these types of exceptions:

  • my business logic exception: display as ordinary plain error message
  • standard system exception: log exception to file, user is given options Abort / Ignore (/Retry) etc...

The best idea I could figure out was to create common ancestor for business exceptions and check it in the handler. I think this was original purpose of ApplicationException which is now deprecated. Do you think I can resurrect it for the purpose or is there some better approach?

  • There's two problems here: one, you are basically trying to differentiate programming errors from environment errors in general, which is impossible. Two, you want to handle business logic exceptions weirdly. In the situations you mentioned, you can't continue. You need to let the user know that something's wrong, and you need to store a log so you can fix it. Jan 7, 2015 at 14:12
  • 2
    I'm a Java guy, but it seems to me that a CLR exception is not by definition a bug or unrecoverable. It depends on the context and the application. For instance, if the user is requesting a file from My Documents, a file not found exception is normal; if you get a file not found exception trying to open an internal file in the application's installation directory, that's likely an unrecoverable failure (e.g. bad installation, user or virus trashed the installation folder, hard drive exploded).
    – Doval
    Jan 7, 2015 at 15:01
  • @Doval - now I understand why you were talking about bugs in context of exceptions - such a a speak is used at Java platform. I have never seen this at .NET plaform so far.
    – miroxlav
    Jan 8, 2015 at 13:22

1 Answer 1


If you expect certain exceptions to be handled at the top level of the program (or close to it), create a specific exception class for them so you can identify them. That way you don't accidentally catch exceptions that arise from program bugs or unrecoverable errors (e.g. out of memory).

I don't know the purpose of ApplicationException but Microsoft's documentation warns against extending it, and I don't think you'd gain anything from doing so. You wouldn't want to catch ApplicationException directly since there might be ApplicationExceptions your application didn't define. So you'd need to create a subclass specifically for your application, and in that case you could just as easily extend Exception.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.