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.

Steve MarshallIT ManagerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
Dustin SaundersDirector 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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Steve MarshallIT ManagerAuthor 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.

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.
Steve MarshallIT ManagerAuthor 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.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.