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?
3
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.
1