C# – Should I make the own exceptions, or co-opt similar exceptions for slightly non-standard purposes

cexceptionsnetobject-oriented

This is a general design question, but I'm focusing on C# and .NET because those are the languages I'm working with right now.

Should I create my own, new exception classes, or co-opt existing framework exceptions for slightly different purposes?

For example, I'm finding myself needing an exception that indicates a member (that is, of a type for example) was expected, but has not been found while reading an assembly using Mono.Cecil. The base class library defines the exception MissingMemberException, which seems to communicate exactly what I want, but the description says:

The exception that is thrown when there is an attempt to dynamically
access a class member that does not exist.

Which doesn't fit exactly, because I'm not dynamically accessing the member, but rather working with the assembly passively.

Best Answer

In general

Subclassing exceptions is a good idea to group the exceptions into the families or groupings that they belong to. It also allows client code the opportunity to handle exceptions based on specific errors or more generally. I usually divide the tree somewhere near the root between the logical and runtime errors (e.g. in C++ the std::runtime_error vs. std::logic_error).

Being able to differentiate between the system exceptions and your application's exceptions is also a good idea. It would be odd if the client code is watching for an system failure of some sort but catches your (via a base class) code's logical error.

Given this case and C#

C# has a rich and large exception hierarchy - I wouldn't try pick up a base class too deep into it. Following on your example, it sounds like your are throwing a logical error (or at least an application error), so the base class or even just that exception would hint at a system error. The exact exception can be debated, but I think in this case it is not a good choice.

Hierarchy

I would build a hierarchy that allows you to distinguish between system and application errors and then further between runtime and logical errors. Do not be afraid to use inner exceptions - catch the system error and wrap it in something more meaningful given the context in which it is being thrown. Don't go overboard, focus on what would be key exceptions. Exceptions can have unique textual descriptions associated with them - use them to give a user even more detail or hints at what to do to correct the problem.

Related Solutions

Is Catching General Exceptions a Bad Practice?

These rules are generally a good idea and thus should be followed.

But remember these are generic rules. They don't cover all situations. They cover the most common situations. If you have a specific situation and you can make the argument that your technique is better (and you should be able to write a comment in the code to articulate your argument for doing so) then do so (and then get it peer reviewed).

On the counter side of the argument.

I don't see your example above as a good situation for doing so. If the logging system is failing (presumably logging some other exception) then I probably do not want the application to continue. Exit and print the exception to the output so the user can see what happened.

Python – When and How to Use Exceptions

The recommendation in Python is to use exceptions to indicate failure. This is true even if you expect failure on a regular basis.

Look at it from the perspective of the caller of your code:

my_status = get_abe_status(my_url)

What if we return None? If the caller doesn't specifically handle the case that get_abe_status failed, it will simply try to continue on with my_stats being None. That may produce a difficult to diagnose bug later on. Even if you do check for None, this code has no clue why get_abe_status() failed.

But what if we raise an exception? If the caller doesn't specifically handle the case, the exception will propagate upward eventually hitting the default exception handler. That may not be the what you want, but its better then introducing a subtle bug elsewhere in the program. Additionally, the exception gives information about what went wrong which is lost in the first version.

From the caller's perspective, its simply more convenient to get an exception than a return value. And that's the python style, to use exceptions to indicate failure conditions not return values.

Some will take a different perspective and argue that you should only use exceptions for cases you never really expect to happen. They argue that normally running running could should not raise any exceptions. One reason that is given for this is that exceptions are grossly inefficient, but that's not actually true for Python.

A couple of points on your code:

try:
    hits[0]
except IndexError:
    raise NotFoundError("No mentions found.")

That's a really confusing way to check for an empty list. Don't induce an exception just to check something. Use an if.

# say we expect four hits...
if len(hits) != 4:
    raise Warning("An unexpected number of hits.")
    logger.warning("An unexpected number of hits.")

You do realize that the logger.warning line will never run right?

Best Answer

Related Solutions

Is Catching General Exceptions a Bad Practice?

Python – When and How to Use Exceptions

Related Topic