Re: Should Derived Classes Provide Custom Exception?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Thu, 14 May 2009 17:00:38 -0700, jehugaleahsa@xxxxxxxxx <jehugaleahsa@xxxxxxxxx> wrote:

[...]
In this context, the implication is that you should avoid adding  
complexity unless you have some qualified, quantifiable gain.  It's  
entirely possible that that gain is in fact a _reduction_ in complexity in  
a different area of the code.  In which case, that may well be a good  
trade-off.  But it's important in adding complexity in one place, so that  
you can reduce complexity elsewhere, that you only add _just enough_  
complexity to accomplish the goal.

Would you say the same things for an application that is expected to
receive maintenance for the next decade?

I'm not sure why that would matter, but...I generally take the assumption that maintenance to the code will be on-going in perpetuity. The fact is, code practically always lives longer than anyone expects it to.

You can assume that my comments are considered to be within that context, if that affects your interpretation of them.

As I've told you before, my
code is rather large and so I get single-minded rather often. I
usually overcompensate. It is something of an art to stop creating
more abstractions. I miss the mark quite often.

For what it's worth, it's often a lot easier to tell someone else to not over-engineer something than to avoid over-engineering something oneself. :)

[...]
Here is what I think I will do. I think I will trash some of my
exceptions. Instead, I think I will create one custom exception for my
database layer. I will simply put more effort into making my error
messages meaningful.

You may well find that more than one custom exception is useful. In particular, the question should be, can you usefully categorize errors that might occur?

But I do agree that making the error messages meaningful can go a long way.

Note, however, that exceptions are almost never as meaningful to the end-user as they would be to someone more technically involved with the application. Frankly, error reporting is a really challenging problem, and I can't say that I've seen anyone do a really stellar job at it.

I have mostly given up, though I have that freedom because I am mostly working on smaller, individual-sized projects these days. I don't usually wind up making custom exceptions, and if I have a need to report an error to the user, I just report the exception Message as-is.

In other projects, two main issues come up:

-- Generalizing the error to avoid presenting the user with overly technical jargon
-- Providing enough detail to the user that they can use to address a problem

These two issues are, unfortunately, mostly contradictory. One particular issue with the first is that, as in your case, each layer of logic often is wrapping a lower-level error and reporting it in a more generalized way. For example, the user might be trying to open a document, which might imply a middle layer that deals with a file object, which might in turn imply a lower layer that does some actual file i/o.

If an error happens, do you report to the user: "failure to open the document", "failure to create a file object", or "failure to access a specific file"? The first is the most likely to be meaningful to the broadest selection of users, but the last is the one most likely to offer specific, actionable information (i.e. that's where things like "insufficient rights", "non-existent file", etc. will be reported).

In one project I was involved with, some time ago, our primary audience was children (roughly 8-14 years of age) which made the whole error-reporting issue even more problematic (especially for the younger end of the range). We wound up with what I'm still not sure was the right design: we reported the most general error, but then tried to provide a short list of most likely things to check for a specific kind of error.

In other words, rather than taking advantage of the information provided by the lowest levels of error reporting, we summarized the error, and then tried to anticipate and report what kinds of things might cause the kind of error. The motivation there was that simply reporting the lower-level information was likely to be too technical for the audience, but we didn't have a reliable way of simply translating that lower-level information into something understandable.

We never got any serious complaints about error reporting in that product, so I suppose it wasn't all that bad. But it never really did sit well with me.

So where does that leave you? Well, what about this whole "higher-layer code shouldn't have to know there's even a database involved" thing? To the code, perhaps that's true. That is, that there's a database involved might be an implementation detail that is irrelevant to the higher layers of code.

On the other hand, if you're going to report an error to the user, and if there is in fact a database involved, wouldn't it be helpful to the user to know that the error was related to the database, especially if the error was due to something the user has control over?

If you've got some mechanism for letting a user drill down into the wrapped exceptions, as part of your error reporting, I suppose that might be okay. But I'd be very wary of wrapping exceptions in a way that causes the information to be available only when debugging.

Perhaps the solution there is in fact to simply make more meaningful messages in the exception. But in that context, "more meaningful" probably means that you need to include some details from the inner exception(s).

Sorry I don't have a magic bullet. It seems like you're on the right track...just keep in mind the issues surrounding error reporting. And in particular, the fact that exception/error reporting isn't just about coordinating the code's operations, it's also about providing the user with information that allows them to correct whatever situation might be preventing the code from making forward progress. Any exception throwing/handling architecture needs to preserve the user's ability to do that.

Pete
.

Relevant Pages

  • Re: Oh boy, how did we miss this...
    ... >This error seems to trigger SEH immediately, but no handler responded because I ... use the OS's own reporting mechanism in a way that was never intended (at ... There are several different error handling mechanisms in Windows... ... Structured Exceptions ...
    (comp.lang.pascal.delphi.misc)
  • Re: Benefits of Dynamic Typing
    ... >> - On the toplevel of the compiler, to report all compile errors found ... > Catching and reporting all exceptions in the toplevel doesn't require ... Note that I don't use exceptions much. ... exception for reporting an end of file though. ...
    (comp.lang.functional)
  • Re: Comparing Calendars between two project files
    ... fields/tables you can use to get exceptions through the Project 2007 ... SDK. ... You can save the data from the reporting database through Report> ...
    (microsoft.public.project)
  • Re: Idle Musings
    ... It was just another event to corral the news media into ... reporting what President Obama wished. ... While there were exceptions to ... that the overwhelming articles generated yesterday in regards to his ...
    (misc.news.internet.discuss)
  • Re: Comparison with False - something I dont understand
    ... exceptions remove a ton of complexity and almost universally ... Error handling in C huge source of bugs. ... error conditions within worker processes. ...
    (comp.lang.python)