Exceptions Are For Exceptional Circumstances Is Not A Value-Add Answer

Some exceptions tend to scare end users. My end users are largely loan officers, clerks and data entry specialists (not techy at all). If I don't handle an exception from the database, for example, the nerdy column-does-not-allow-null and syntax-error-at-procedure-line-57 messages downright terrify my users. They're afraid they broke something and will be blamed for it.

So if I throw an exception, it's in plain English. If you put a little effort into your exception messages and details, it's better than a crash or silently doing nothing.

How you affect others is a good reason to throw an exception.

I really like this definition!

One thing I notice a lot is methods that return a boolean for "success". I can understand how this might be needed in a REST API or something but the rest of the time I would rather have my methods return a meaningful value or nothing at all. I assume it will work. Otherwise it should raise an exception.

As you said, other code can handle exceptions in a way that the user isn't exposed to a raw error message.

If it fails, though, I want my system to get some information on the failure that I can use to make sure it doesn't fail again.

I had been trying to formulate a guideline in my head for this, and this wording really hits the nail on the head for me.

@WebManWalking & @Ben: your exceptions should NEVER get to the UI anyhow. Exceptions are for developers. Error pages are for users. Indeed generally any developer-useful exception information would actually be a security consideration if bled to the user.

So if you're doing that: you're doing it wrong.

My chief use for exceptions is to mask side effects of unexpected behaviour in my code (my code's "fault"), and bubble back something useful to my user... where my user is *the developer* not the end user.

I would not bubble back a "division by zero" exception to my user if the fact something was divided by zero because my code did it (say an unexpected 0 was passed as an argument which is then used as a divisor. I'd catch that, and raise an ImvalidArgumentException (perhaps with a message "argument x must be a positive integer").

I use exceptions to *clarify* exceptional situations.

--
Adam

I am with Adam.

When I learnt programming back in the late 80's, that was the one thing that was drummed into my head. If your block of code can error, then you need to throw the right exception and handle it upstream.

Can you imagine clients connecting remotely, then the application errors, but the client doesn't get the error and just hangs. The client needs to know that an error occurred, the only way to do this is throw an exception and provide the details the client needs to be satisfied.

Common sense, dictates that you need to hide most exceptions in your code, that means also using try/catch blocks more as well. Without it, as Adam states, you're not doing your job right.

@All,

Ben asked for a reason to thrown an error, and ameliorating a raw exception message by substituting a friendlier one is a reason. But here's an idea some of you haven't considered. Why does it have to be either/or?

You control your code. You set your own conventions that make for a more stable environment. Why not define your own response object that contains properties (or struct keys) for both plain-English and technical error messages? That way they travel together (and can be serialized together if you so choose). One message may ultimately find its way to the screen, the other to an email to the developers. That too could be part of your coding conventions.

If you know some stable categories of common errors and a wide customer base, maybe internationalize them to avoid scaring your Spanish-speaking audience too.

There's no reason the same error couldn't have multiple audiences.

The easiest way not to let a specific error reach the end user is the way HTTP does it (500 Internal Server Error) or MSIE's generic "an error occurred" screen that helps no one. Do you *like* unhelpful emails that say "Your page doesn't work. Fix it!" with no details to go on? Then fine, at the time you actually know what you were doing that caused the error, don't propagate it. Just block it.

But if you want to encourage your users to report back something that gets you into the ballpark of where/what/why the error occurred, but NOT the raw message, you have to perform that translation yourself.

I have to live in my future. Part of that is having to support the code I write. So at original coding time, I like to put in some extra effort to make my future a happier place.

A well-designed app handles exceptions and errors to prevent app crashes.

For example

public function ReadAll(fileToRead)
{
try {
if (fileToRead == null || fileToRead == "") {
Debug.Log("Idiot you must pass a valid filename to use!!");
Throw(type="myApplication.ReadAll",message="Filename can't be null or empty"); ;
}
// Code block to read filestream
} catch (e) {
Debug.Log("Something happened reading file stream...");
Throw(type="myApplication.ReadAll",message="Something interrupted the reading of the filestream"); ;
}
return something;
}

In this example, the user of the Application doesn't need to know a developer screwed up, the Application itself needs to know and handle it accordingly. I do this all the time with my Applications, although this is maybe not the best example of using exceptions. In a case like this, you could have a central exception handling, that logs or does what it needs to do. Provided that the code is allowed to bubble back up, not throwing exceptions and dealing with them, is just bad practice in a lot of languages period.

If done right, all the user of the Application will see, is an error message tat something went wrong and is still free to click on other aspects of the Application. If it's serious enough, you point blank log the frigging thing, but under all circumstances you must deal with exceptions and stop the Application from stopping on exceptions where possible.

Throwing a 500 server error in cases like this is, stupid to say the least.

It seems to me that we are all in agreement that exceptions shouldn't make it all the way to the user and that our applications shouldn't crash.

Yet the word "stupid" has made it into the conversation and the tone no longer seem friendly. I'm confused by how so much agreement seems to be generating so much heat.

I'll see myself out.

I think you're being a bit precious Steve. If Andrew things something is stupid, why should he *not* say that? Why would you - indirectly - suggest he should not express his opinion?

Hardly any discussions which contain no dissenting opinions are worth actually having, IMO. They're just self-congratulatory circle-jerks.

Instead of shrinking away, why don't you weigh up what people have said, then offer your own conclusions? That'll help both you and the discussion. Don't be worried about disagreeing with people, and don't worry too much about people disagreeing with *you*. This is how we all fine-tune our understanding of things.

So... what do you think?

--
Adam

@Steve,

Tone!

I think throwing a 500 server error is stupid, but as the post was about the way we think about the use of exceptions and not whether we capture them or not, I think it is fair to say that we should not need any excuse or reason to throw an exception that we need to catch later.

I also gave a very good example, of when one should think about adding exceptions to their code.

And yes, throwing a 500 server error, is the worst thing you can do, which by definition is just being plain stupid.

Ben,

That's the sort of thing that I do as well, for example, if we go back to my earlier example. There are times when we throw an exception deliberately, with specific values. One is to identify the function and the other is to identify the reason/severity, as in the example I posted earlier, the first thrown error would not really be logged as this is really a developer being stupid. But for Unit Testing, when the error is thrown we can identify straight away what is going on.

But for logging and other general visual displaying, we use the other attributes as mentioned to say oh we deliberately threw this error and it's somehow escaped our traps further up the chain.

I guess there are many ways that work for everyone, but the one thing that I should reiterate, is that we should not be scared to throw exceptions that we need our application to handle and take the correct action, where the user doesn't even need to know about it. These are usually our warning type messages, or even decision exceptions for the application. Basically anything that is not meant for the users eyes is caught, logged and we move on with the show.

Anything that is meant for the user, is then logged and a user friendly message is sent back to the client that issued the request.

Sorry I guess I expressed myself badly. I wasn't trying to criticize the tone (though I do find it a bit frustrating) so much as I was trying to understand the nature of the disagreement.

It seems like we are all saying that it is helpful to have exceptions return enough information for us to debug the problem but that those exceptions shouldn't make it to the end user. Not so?

Ben,

Why do you think that feels "leaky"? It sounds like a good solution to me.