OneTrueError is an open source error handling service. It includes the context information that you forgot to include when you logged/reported the exception.
Continue reading “OneTrueError – Open source exception management for .NET”
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 has a complete WCF integration following the same pattern as WCF. It makes it a breeze to capture and analyze errors in WCF applications.
Continue reading “OneTrueError and the WCF integration”
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
Continue reading “OneTrueError and ASP.NET”
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 “Updates to OneTrueError”
OneTrueError.com is my new startup for .NET developers. It’s a bit like ELMAH, but for most of Microsoft’s different frameworks, and with a tad bit of analytics.
Continue reading “Introducing OneTrueError.com”
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 “Throwing exceptions”
This article will teach you how you should design your exception classes. It’s a follow up to my previous article which told you what exceptions are and their intended usage.
Continue reading “How to design exceptions”
This article will explain what exceptions are and how they differ from regular errors.
Continue reading “What are exceptions?”
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”
If it were just me, I would simply just print something like:
“Oops, something unexpected happened. Please try again or contact the support department”
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.