OneTrueError – Open source exception management for .NET

OneTrueError is an open source error handling service. It includes the context information that you forgot to include when you logged/reported the exception.
Introduction

Continue reading “OneTrueError – Open source exception management for .NET”

OneTrueError and the WinForms/WPF integration

OneTrueError is a new startup which also is a member of Microsoft BizSpark. This post is about the client library for WinForms/WPF. It will catch and handle all uncaught exceptions automatically. The errors are also uploaded to our site for analysis to enable us to suggest possible solutions

Continue reading “OneTrueError and the WinForms/WPF integration”

OneTrueError and ASP.NET

OneTrueError is my new startup which also is a member of Microsoft BizSpark. This post is about the client library for ASP.NET (WebForms/MVC/WebAPI). It will catch and handle all uncaught exceptions automatically. The exceptions are also uploaded to our site for analysis to enable us to suggest possible solutions

dashboard2

Continue reading “OneTrueError and ASP.NET”

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 “What are exceptions?”

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.