Как реализовать обработку исключений верхнего уровня?

Положить его обратно.

Исключение должно быть актуально только во время тестирования. В противном случае не имеет смысла выдавать его пользователю.

Ведение журнала в порядке.

Вы можете дополнительно использовать символ DEBUG, определенный Visual Studio для отладочных сборок, в качестве флага.

    ...
    } catch( Exception e ) { 
#if DEBUG
          throw;
#else
          log as usual 
#endif
    }

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

В любом приложении Java вы почти всегда хотите определять обработчик исключений для неперехваченных исключений примерно так:

Thread.setDefaultUncaughtExceptionHandler( ... );

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

В дополнение к этому, у большинства моих потоков есть попытка / улов, где я поймаю RunnableException (но не Error) и записываю его ... некоторые потоки умрут, когда это произойдет, другие будут регистрировать и игнорировать, другие будут отображать жалоба пользователю и позволить пользователю решать, в зависимости от потребностей Приложения. Эта попытка / уловка находится в самом корне потока, в методе Runnable.run() или эквивалентном. Поскольку try / catch находится в корне потока, нет необходимости иногда отключать этот улов.

Когда я пишу на C #, я кодирую аналогично. Но все зависит от необходимости приложения. Исключение, которое повредит данные? Что ж, не поймите и не игнорируйте это. ВСЕГДА регистрируйте это, но затем дайте приложению умереть. Однако большинство исключений не относятся к этому типу.

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

Имейте в виду, что его следует использовать как страховочную сетку. Тем не менее попытайтесь перехватить все исключения, прежде чем они поднимутся так далеко.

Стремление уловить все исключения и сделать программу «стабильной» очень сильна, и эта идея действительно кажется очень соблазнительной для всех. Проблема, как вы указываете, заключается в том, что это всего лишь уловка, и программа вполне может содержать ошибки и того хуже, без признаков сбоев. Никто не следит за журналами регулярно.
Я бы посоветовал попытаться убедить другого разработчика провести обширное тестирование, а затем развернуть его в производственной среде без внешней ловушки.

Если вы хотите видеть исключение, когда оно возникает, в Visual Studio вы можете перейти в меню ОТЛАДКА, выбрать ИСКЛЮЧЕНИЯ, и вы можете указать отладчику, чтобы он прерывался, как только возникает исключение. Вы даже можете выбрать тип исключений. :)