CODEWITHSUNDEEP
c#
Oleg Vazhnev
Oleg Vazhnev

Reputation: 24067

is it possible to log all thrown exceptions during program execution?

I have C# application. I can compile it in debug mode, with any flags etc. if required.

After some point it doesn't function properly (significant slow-down, partly hangs etc. etc.)

Obviously something goes wrong. As a first try I want to see complete list of all exceptions that hapened anywhere during program execution (caught and uncaught). Is it possible? I know there is an option in VS that allows me to "brekpoint" at certain exception. But I don't want to "breakpoint", instead I want to "log" all happened exceptions so I can analyze them later.

Upvotes: 2

Views: 315

Answers (3)

Pete Baughman
Pete Baughman

Reputation: 3034

To answer the question as asked, you will likely need to (at least partially) create your own debugger that will attach to your process and record all unhandled and handled exceptions. This is probably where you want to start. Also, here is the MSDN Documentation for the debugging interface.

This should let you do exactly what Visual Studio does when you go to Debug -> Exceptions and check the box to break when an exception is thrown. The only difference is that instead of stopping execution, you should be able to record information about where the exception is thrown (and I think the type of exception). The first thing you'll notice is that this is extremely complicated. Hopefully the mdbg sample is close enough to what you need that you can just tweak it slightly.

I will also disclaim that this probably isn't the best way to solve the underlying problem that you're trying to solve. If there are unhandled exceptions in your program, you probably shouldn't need any extra help finding them. They should bubble up to the surface unless the code does things like this:

try
{
    . . . Some operation
}
catch(Exception){ } //Muddle on through - Very Bad!!!

If the issue is that there are handled exceptions that aren't getting handled properly, then the above approach won't do much to help you narrow down what the problem is either

Upvotes: 0

Furqan Safdar
Furqan Safdar

Reputation: 16698

Try to use UnhandledException in you application if you are not sure where exceptions can occur possibly.

The UnhandledException event handles uncaught exceptions thrown from the main UI thread. The ThreadException event handles uncaught exceptions thrown from non-UI threads.

static void Main(string[] args)
{      
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
    //... do something ...      
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
      System.Diagnostics.Trace.WriteLine((e.ExceptionObject as Exception).Message, "Unhandled UI Exception");
      // here you can log the exception ...
}

I have used Trace class on MSDN for logging:

System.Diagnostics.Trace

This includes listeners that listen for your Trace() methods, and then write to a log file/output window/event log, ones in the framework that are included are DefaultTraceListener, TextWriterTraceListener and the EventLogTraceListener. It allows you to specify levels (Warning,Error,Info) and categories.

Upvotes: 3

Charles Bretana
Charles Bretana

Reputation: 146499

Frankly, You shouldn't use exceptions for this. What you need is to "instrument" the application to log critical activities within the code, with date time stamps, so that after something goes wrong, you can review the chronological logs and see what, (and where) the code is either failing to do what is expected, or taking longer than it should. Check out Microsoft Logging Application Block, or log4Net

In general, the proper use of Exceptions should be limited to cases where the application, (or module, or subroutine/function), cannot successfully complete whatever function it has been designed to provide. Exceptions should be logged as well, but exceptions should not be used to track anything other than critical failures. If the code cannot recover from a failure, it should, in most cases, simply cause the app to stop.

In fact, most of time when something goes wrong and an Exception is thrown, (except for the most trivial problems), the information available at the point where the exception was thrown is only the very first step in diagnosing the issue. What happened in the code execution path prior to that is more often where the real issue is...

Upvotes: 3

Related Questions