Необработанные исключения в библиотеке классов C # для целей ведения журнала

Я новичок в разработке программного обеспечения, а также новичок в stackoverflow, так что не беспокойтесь.

ИСТОРИЯ ВОПРОСА : Я разрабатываю библиотеку классов C #, которая обрабатывает xml-сообщения, отправленные сторонним приложением по tcp / ip (с использованием сокетов Async). Я использую com-interop, чтобы предоставить библиотеку классов приложению Vb6. Когда библиотека C # обрабатывает xml, который она получает через сокет, она вызывает различные события, на которые подписывается потребляющее приложение vb6 (таким образом, когда мы в конечном итоге переписываем все приложение в .Net, мы уже закончим с этим компонентом).

ВОПРОС: Я хочу перехватывать все необработанные исключения ТОЛЬКО ДЛЯ ЦЕЛЕЙ РЕГИСТРАЦИИ. В приложении winforms вы можете подключить событие к AppDomain.CurrentDomain.UnhandledException и Application.ThreadException. Нет ли возможности аналогичным образом получить данные об исключениях для регистрации информации в библиотеке классов?

Важные моменты:

• Я не пытаюсь восстановиться после этих исключений, а просто регистрирую их, позволяя исключению распространяться и приводить к сбою app, если потребуется.

• Я изо всех сил стараюсь улавливать все определенные исключения локально, где бы я ни знал, что они могут произойти. Поэтому моя цель - просто регистрировать поистине неожиданные исключения.

• Я знаю, что некоторые скажут, что это плохой шаблон проектирования. Вместо этого я должен позволить вызывающей стороне обрабатывать эти исключения. Проблема в том, что приложение vb6 не имеет такой надежной обработки ошибок, как хотелось бы. В первую очередь, я хочу регистрировать трассировку стека, чтобы в случае сбоя приложения vb6 из-за моей dll я мог просматривать журнал, чтобы получать предупреждения о потенциальных областях моего кода C #, которые, возможно, необходимо изменить.

Может ли кто-нибудь дать мне какое-то направление? Лучший вариант, который я нашел до сих пор, - это поместить общий блок try catch в каждый общедоступный метод, зарегистрировать исключение и затем выбросить его. Это кажется далеко не идеальным:

public void SomeMethod()
{
    try
    {
        // try something here...
    }
    catch (Exception ex)
    {
        Log(ex);
        throw;
    }
}

Это не только кажется плохим дизайном, но, кроме того, я не знаю, что произойдет, если один из асинхронных обратных вызовов вызовет исключение в потоке, отличном от того, в котором был вызван метод. Будет ли этот общий блок try / catch перехватить такое исключение?

Спасибо за любую помощь.

РЕДАКТИРОВАТЬ: Первоначально я пометил ответ @Eric J. как правильный, но после попытки реализовать решение я обнаружили, что он не будет работать с обратными вызовами async из класса сокета, который я использую. Как только поток threadpool используется для запуска асинхронного обратного вызова, я не могу уловить никаких исключений, которые возникают позже в стеке. Нужно ли мне использовать среду АОП или есть какой-либо другой способ отловить эти исключения?