Posts tagged with: exceptions



Updates to OneTrueError

Bug fixes

OneTrueError has gotten some bug fixes. A windows update of .NET framework gave us a bit of a down time. Won’t happen again. Fortunately the client library always continue to try to deliver reports if something fails. So nothing should be lost even if the report site is temporarily down.

Continue Reading



Throwing exceptions

Throwing exceptions is in itself trivial. Just invoke throw with an exception object. But when should you throw? Should you create a new exception or rethrow an old one? What should you include in the exception info?

Continue Reading



What are exceptions?

This blog has been quiet for a while. I am currently writing a book about localization. Me and my partner is also getting close to release of our new startup. One of it’s features is to automatically catch unhandled exceptions and send them to a webservice for analytics. But to take full advantage of that you’ll have to use a set of exception handling best practices. I’m therefore going to write a set of exception articles. The series will end with the release of our service.

Continue Reading


Dealing with exceptions, Logging and displaying error messages

I got a client which is really firm on that the user should know what went wrong when exceptions are thrown. So we are displaying error messages like

“The database did not respond”
“The database operation failed”
“Failed to load configuration setting X”

etc etc.

If it were just me, I would simply just print something like:

“Oops, something unexpected happened. Please try again or contact the support department”

Why?

Ok. So let’s assume that we show the user a more detailed error message. What is he/she supposed to do with it? Remember, it’s from an exception. If something exceptional happens it unlikely that the user can fix the problem by reading an error message. At tops the user can try do perform the operation again.

When the user have got tired of trying he/she calls the support department. If we’re lucky the user manages to quote the error message exactly. But really. Do that help us? Not really. We still have to go through our logs to find out what happened.

The correct approach to dealing with exceptions

So what should we do when an exception happens? Well. Try to prevent it from happening in the future. That goes for all exceptions. Some can be prevented, whilst others can’t. The point is that we should at least try.

To be able to try to fix the exceptions we have to find them. Using a big fat log for everything is not a very good way. Instead try to have a seperate log for all unhandled exceptions. Make sure that you read that log. You might want to build something that emails that log to you daily.


When to throw exceptions

I’ve written several posts about exceptions. For instance when you should catch them or how you should design them. In this post I’ll discuss when you should throw exceptions.

Exceptions are thrown when something exceptional have happended. But what does that mean? In fact it’s really simple. Let’s look at an example interface:

interface IUserRepository
{
	void Save(User user);
}

You should throw an exception every time that method fails to save the user into the data source. The failure reason do really not matter. All of these reasons are valid:

  • The user object do not contain all mandatory information
  • The user object is null
  • The data source is off line
  • The data source rejected the save.

Why? Because the method is named Save and returns void. That is, the contract of the method indicates that a save should in most cases be successful. Hence something exceptional have happened if the user is not saved into the data source.

But couldn’t you have written something like this instead:

interface IUserRepository
{
	bool Save(User user);
}

Yes, sure. That method would return false instead of throwing exceptions. But the method contract indicates that the method can fail as many times that it can succeed. You really do not mean that, do you?

but.. but… The Remove method usually returns a bool.

interface IUserRepository
{
	bool Remove(User user);
}

Yes. It do. The reason to that is that it says that it’s OK to call Remove even if the user do not exist. imho it’s a vague contract. It’s not clear if the method means that the removal is expected to fail or if the method allows you to remove non-existing items. I would have used void as return value instead.

Myth: Exceptions are expensive

First of all: Exceptions that are not thrown are not expensive.

And if you start to think about it, exceptions are actually a lot cheaper than using return values. Exceptions forces you to take action, no action means that your application crashes. The exceptions also include the exact location of the error. Return values only work if you check and handle all of them. I would like to see any reasonable sized application which uses return values where all of them are handled.

The point is that it’s a lot more tedious task to find and fix bugs in applications that uses return values instead of exceptions since you have to use details logs or reproduce errors to be able to locate and fix them. The amount of time spend to locate and correct errors probably costs a lot more money than buying new hardware to make up for the exception performance penalty.

Summary

Throw exceptions if the method contract is violated.


Pages:12