views:

127

answers:

1

Hi

I'm starting a new project, a end-user desktop application. I'm a concerned about what will happened if (ok, when) the end-user gets an unhandled exception. Asking the user to help me reproduce the bug is not an acceptable option. As I see it I'm left with one option: to upload an error report to my server.

Years ago when I were a Delphi developer, a great tool called madExcept could help me with all this, but I cannot find a similar tool on the .Net framework. So I guess I have to make my own.

Here is my idea

  • Use a log-framework and write a few well thought log entries, not too many or few. Just log to memory, better performance and I don't need the file. Limit the log size to say 100KB.

  • Use AOP to log parameters and return values on all methods, except those in a tight loop as it will clutter the log and cause bad performance. This is the point I'm really insecure about, is this a stupid thing to do in production? The benefit seems very appealing though. I think I should be able to reproduce the exception in a lot more cases, than having just a stack trace and a log. Also this will logged to a memory and limited to something like 200KB.

  • Catch all unhandled exceptions, here I will upload the two logs and stack trace to my server.

What do you think will it work? Is there a better way?

Thanks

+1  A: 

Do you expect to have many unhandled exceptions?

Just catch unhandled exceptions at the application level, and log them. Do catch exceptions locally when it's necessary to add additional information:

public void OpenConfigurationFile(string filePath)
{
    try
    {
        File.Open(filePath, ...);
    }
    catch (IOException ex)
    {
        throw new InvalidOperationException(
            String.Format("Can't open configuration file {0}", filePath), ex);
    }
}

That way, you'll not only log the FileNotFoundException, but also the fact that it was a configuration file you were trying to open.

John Saunders
>Do you expect to have many unhandled exceptions?---I hope not. I would like to provide a stable application, so one is too many, if that's what you asking? I know that's not realistic to have a bug free app, but in this case I want to be better than just the acceptable.---Your example is good, but the exceptions I'm thinking about is not "predictable" exceptions causes by external dependencies. It's more like InvalidOperationException and NullReferenceException. Things caused by invalid logic, what I would call a bug, but people have different definitions of the word.
Karsten
Are these external dependencies that you cannot test?
John Saunders
>Are these external dependencies that you cannot test?Sorry I don't understand what you mean?
Karsten
Ahh okay, if I get you right. You suggest that I should test my code before releasing to get a error-free app? Sure automated tests will find many bugs, but I have yet to see an error-free app no matter how many high a test coverage you have.
Karsten
I suggest you do enough testing of the external dependencies to make such an elaborate logging mechanism unnecessary.
John Saunders
As I said, my focus here is not on external dependencies and I don't see tests as sufficient for getting a real stable system.
Karsten