Question

I’m completely tired of all the buggy code I’ve been writing for all this time and so it looks like I really need to understand the correct approach for working with exceptions.

Let’s consider the following example:

interface IDataSource
{
  string ReadData(int offset);
}

class FileDataSource : IDataSource {...}
class DatabaseDataSource : IDataSource {...}

If I’m using an object of class that implements IDataSource, what are the exceptions I can expect to catch if ReadData() fails for some reason?

FileDataSource can fail because there’s no file, or file is less than offset. DatabaseDataSource can fail because it can’t connect to the database, or there’s no required table in that database.

When I do this:

var data = dataSource.ReadData(10);

What should I catch? From the other side, if I’m implementing a new class FakeDataSource, what should I throw if something bad happens?

I have a feeling that when I throw FileNotFoundException from FileDataSource or SqlException from DatabaseDataSource it means encapsulation violation, since I know implementation details.

Should all the exceptions thrown by any IDataSource be bound to this interface? What I mean is – when I define any new abstraction, should I also define the related exceptions? Like this:

interface IDataSource { ... }    
abstract class DataSourceException : Exception { ... }

So, when someone decides to implement IDataSource, he should only throw DataSourceExceptions. Is that correct? What about wrong values for offset – should I still throw DataSourceExceptions or standard (.NET) ArgumentOutOfRangeException is OK?

Would also appreciate any links to the articles about error handling you consider worthy.

Answer 1

You should only catch the exceptions that you can handle. If your IDataSource throws FileNotFoundException or SqlException and you can’t handle it, don’t catch it.

When throwing exceptions, you should throw the type of exception that best describes the problem. There are three things that you want to know from a thrown exception.

• What went wrong?
• Where did it go wrong?
• Why did it go wrong?

When exceptions are used effectively, what is answered by the type of
exception thrown, where is answered by the exception stack trace, and
why is answered by the exception message. If you find your exceptions
aren’t answering all three questions, chances are they aren’t being
used effectively. Three rules will help you make the best use of
exceptions when debugging your programs. These rules are: be specific,
throw early, and catch late.

In most cases use commonly defined exceptions rather than creating your own. People will be familiar with them and understand what they mean without additional explanation. However, creating your own exception type may be helpful in cases where it is desirable to encapsulate details for a particular module. When taking this approach, wrap the original exception within the exception for your module so that the information doesn’t get lost when it is rethrown.