Programming practice: exception handling

[MrGibbage]

I am writing a class that I plan to reuse, so I want to make it generic (for reading, writing, creating xml files to store application settings). My question is, is it better to put the exception handling in the class (such as file read errors, etc), or is it better to leave them out of the class and have them handled at the.. um.. "application" level (that is, the level where I call the methods in the class)?

If I put the exception handing in the class, then I won't have to worry about it when I write my program because I know the exceptions will be handled, but it doesn't give me the flexibility to do what I want should I decided that I want to do something different for a specific situation.

Is there an easy way to get the best of both worlds?

I am leading towards putting the error handling in the class to make my programming easier.

Skip

[HanneSThEGreaT]

Call me stupid, but I'd put error handling in both the class as well as the application that uses it

[shollon]

For myself, working in the real world, it really all boils down to logging of the error that can be utilized for debugging purposes.

If you have no class exception handling, then you do get the stack trace rather easily on those unhandled exceptions, but that comes at a cost. If you main app makes a function call that ends up going into several functions, then any one of those calls could be the culprit and making it a troubleshooting nightmare when supporting it.

if you have class exception handling, then you can handle the errors as they come up and then try to recover from them at run-time without just popping up a message.

General rule of thumb I always use is "FOR SURE", use error handling when interacting with an outside entity (i.e. FileSystem, Database, etc..).

So I guess my opinion is to design your error handling in such a way where you still implement Class level handling...but also do something to not just throw an exception, but design it in such a way where you can keep your "Stack Trace" too, but also keep good error logging for troubleshooting purposes.

Not sure if that answers any questions and/or exceeds the scope of your class, but those are my two cents.

[Mutant_Fruit]

The rule is quite simple, if you can handle the exception and produce a useful output then do it. If you can't handle the exception and do something useful, then don't catch it.

Two examples:

public static int Parse (string value) { }

public static bool TryParse (string value, out int value) { }

In the first case, there is nothing useful you can do if an invalid string is passed. There is no way to signify an error case without throwing an exception so you shouldn't attempt to catch the exception here.

In the latter case, every possible exception should be caught as it is possible to easily return an error condition (return false) to signify something has gone wrong. That's the entire point of the Try* variants on different parse methods. These shouldn't throw exceptions.

When designing a library you'd probably favour the "do not catch exceptions" approach as the only place you know what should be done is in the application using the library. For example if the user of your library says "Open and parse this configuration file" and the file doesn't exist or is corrupt, the user of the library is who should decide if they need to regenerate a new configuration file, automatically restore an old backup or prompt the user that the file is toast.

[CreganTur]

Where I work all exception handling is done at the application level with one exception: if you are going to perform a specific action based on a type of exception, then that would be written into the class.

[boudino]

I agree, but I see one other option: you could use trivial exception handling which wrapps the original exception to your specific one, e.g. ConfigurationException, which allows consumers of the class to easily distinguish between exceptions in configuration hanling and other exceptions.

[MrGibbage]

Wow, these are some interesting things to consider. Thanks for the feedback!



Skip

[sotoasty]

In some instances, we allow the application to decide how it wants errors dealt with. In these instances we will put in the constructor whether the class is supposed to bubble up exceptions, log exceptions or in some cases ignore the exception. It take a little more coding in the class, but gives the application the option.

[TheGreatCthulhu]

I'd back up Mutant_Fruit on this one.

Just think about what kind of error you're anticipating. If your application/library can come up with a way to recover from it and continue it's normal operation, then handle the error internally.
If it can't than throw an exception and let the client code handle it.

This somewhat depends on the design goals. For example, if the application/library must for some reason work no matter what, even if it's only going to dismiss the invalid input and use a default value, then you can imagine that the client code will not be handling many exceptions (if any).
On the other hand, if it is critical that the data or some other condition is in a valid state, before normal and meaningful operation can continue, then an exception must be thrown and a client must decide what to do with it.
Also consider sotoasty's remark: who will be your user group, and do they require a certain flexibility regarding the exception handling.

Think of it as of another way to inform the user what exactly is your interface about, what it does, and how it's meant to be used. Which means: think it through, design it well, and don't forget to document it.

[BigEd781]

In some instances, we allow the application to decide how it wants errors dealt with. In these instances we will put in the constructor whether the class is supposed to bubble up exceptions, log exceptions or in some cases ignore the exception. It take a little more coding in the class, but gives the application the option.

Yet that still causes unpredictable behavior. You just added an option. Which option is used at what times may be inconsistent throughout your program. That approach just seems to complex and error prone for me. I'm with Mutant as well; handle errors where you can, otherwise let them bubble up. A simple and predictable model.

[boudino]

I would say e.g. Exception Handling Block could help to make such an approach more versatile.