Structured Exception Handling


We are currently in the first stages of extensive application rewrites from Access VBA & Access Databases to C#.Net & SQL Server databases, and I have a general question regarding the use of structured error/exception handling.

I am used to the unstructured handling that is part of VBA, and can see that the offerings of C#.Net are far more powerful. I have done a lot of reading, but am struggling to find any examples with enough meat on them to clearly demonstrate what the authors are talking about. They are fast and free with what to do and not do, but there are rarely any solid examples to back up the text.

It is clear that I should be shot without question if I catch a general Exception, and that a routine should catch & handle errors that it's own code causes, but errors caused by external factors should just be passed back (bubbled up I think the phrase is), but my question is this:

If your routine uses a function such as opening a file the name of which is passed as a parameter, should it trap every possible exception that is returned by the File.Open in a specific catch block, or is this overkill?? Should it only handle the IOException and then bubble up exceptions that are to do with invalid filename or directory as it was not responsible with generating the filename/path??

I know this is a basic question, but I want to be sure to get the exception handling right at the start of this long path rather than set off along the wrong route and have to go back.

Some examples or link to examples with meat to them that show best practices would be greatly appreciated.

Who is Participating?
Dustin SaundersConnect With a Mentor Director of OperationsCommented:

See link above for MSFT best practices.

What I tend to do is start with the core methods and work outward, then log exceptions to a file that can be reviewed while cleanly returning users to their previous screens with an 'oops!' message.  When looking at parameters, your app can handle basic validation on variables in code and direct users to correct problems.

You can create user defined exceptions-- but for most common things I've found the normal exception messages are sufficient to pinpoint the problem.  If you have an exception on something like a file copy, in the output to log file as described above you can include the variables used when the error occurred.
louisfrConnect With a Mentor Commented:
If your function gets a parameter, and that parameter is incorrect, you should throw an exception.
You can do that by checking the parameter and throwing an exception, or call another method which uses it and bubble up the exception.
Only handle an exception if you're going to do something about it.
matthewgreenAuthor Commented:
Thanks for the link Dustin.

That is one of the documents that I have read and found the examples lacking. Maybe this is just a case of get on and do it - I was just after a "real-world" example of unwrapping from procedure calls three or four levels down when an error occurs as a result of something that the lower routine was passed rather than generated.

I am starting to think that this is very much going to be a case of working to the Best Practices that I have read and then do what feels right, and then just learn from my mistakes.

I was just trying to get a good "real" example of these best practices in practice rather than the very "basic" examples that most documents tend to give when discussing them.

louisfrConnect With a Mentor Commented:
In your example, you are passed a filename and you use it to open the file.
If you have something to do when that file doesn't exist (such as a default filename to use), then check the existence of the file before calling File.Open. If you want the caller to receive a FileNotFoundException, then call File.Open without catching the exception. If you want a more specific exception to be thrown, check the file exists and throw a custom exception otherwise.
matthewgreenAuthor Commented:
I have read some of the articles again and with those, the extra comments added here, and talking to a previous colleague who develops in C# I have a better (though not complete) understanding. In essence it seems to boil down to the following:

1. Code out as many issues as you can by checking before using anything. Do not rely on accurate data.
2. Trap specific exceptions when you intend to recover in some way (or re-try before failing)
3. Allow all others to bubble up
4. At a higher (maybe even top) level trap un-recovered errors and log

What was throwing me was the static analysis tools saying never catch a General Exception .... when the reality is that eventually that is precisely what you have to do.

I have enough to move forward and it will be a case of learning as I go.

Thanks for the help and pointers.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.