How to catch all un-handled exceptions in a .net assembly (library type, not application)

10,885

Solution 1

In my opinion, putting such logic inside library is not a good idea. I think it should be application responsibility to decide how to deal with exceptions (both handled and unhandled). However you might look at AppDomain.UnhandledException. You can install such handler for CurrentDomain and do something there. However doing this way you are restricting usages of you library (for example implying that library would be used only in one domain). Also you will receive notifications for all unhandled exceptions even totally unrelated to your assembly.

I think that better idea is to allow developers that use your library to do their job dealing with all unhandled exceptions (possibly with UnhandledException installed by the application).

Solution 2

You can use AppDomain.UnhandledException Event to catch unhandled exceptions globally:

http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Or use try/catch for every assembly call.

Share:
10,885
Jules
Author by

Jules

Updated on June 26, 2022

Comments

  • Jules
    Jules almost 2 years

    I have an assembly containing a number of classes. This is a class library type assembly, not a windows forms application. It's also single threaded.

    Is there a way to catch all un-handled exceptions so that I can log them?

  • Jules
    Jules about 14 years
    Hi, I've seen that event but I don't know where to connect to it. There is no Sub Main for a library.
  • Jules
    Jules about 14 years
    So from within my library I log the exceptions that I catch. Anything unhandled is up to the application, that uses the library, to log. Is this the accepted way of doing it?
  • Alex F
    Alex F about 14 years
    Global exception handler can be used in your own application, which references another assembly. It may log every unhandled exception in the whole application, not only in this assembly. If this is not what you want, use exception handling in every assembly call.
  • SergGr
    SergGr about 14 years
    Yes, I think letting caller to deal with your exceptions is the proper way. If caller for some reason leave it unhandled - this is a caller's choice and responsibility. Actually, I'm not sure what and why you want to log from within you library. I think this significantly affects what you should do. What is the expected usage of that "log"?
  • Jules
    Jules about 14 years
    I'd assumed it was up to me to log errors in case a user of the library didn't. I'm self taught in the .Net world, so this is all new to me.
  • SergGr
    SergGr about 14 years
    Yes, you might want to log something. But what and how to do this depends on the reason you do this and your reasons are unclear. Anyway it seems that logging should be customizable by caller. At least there should be a way to disable it at all. Imagine that some application that uses your library is run with no permissions to write to file system (or wherever you write your log to). Would you like to crash the application by your logging in such case? I don't think so. To provide customization you might want to use some logging library such as log4net.
  • Richard Stagg
    Richard Stagg about 14 years
    Without a fixed entrypoint, it might be better to handle exceptions on a per-call basis, avoid the catch-all approach. It's a design flaw in the framework IMHO.