Лучший совет, который я слышал по этому вопросу (на самом деле где-то на SO), был «поймать исключение, только если вы собираетесь с ним справиться». То есть имеет смысл использовать блок catch в этом методе, только если у этого метода есть средства обработки исключения. Например, если метод должен по какой-то причине всегда возвращать значение, а исключение либо записывается в журнал без вывода сообщений, либо каким-либо образом указывается в значении (например, сообщение об ошибке, прикрепленное к некоторому пользовательскому DTO или чему-то еще). Нет ничего плохого в том, что в стеке всплыло исключение и предполагается, что вызывающая сторона его обработает.
Это не значит, конечно, что с этим вообще не следует обращаться. Как вы предлагаете, последней линией защиты всегда должна быть глобальная обработка исключений для приложения. Все ошибки должны обрабатываться изящно, но, что более важно, они должны обрабатываться только тем классом / методом, который должен их обрабатывать, который во многих случаях не является методом, из которого возникло исключение. Например, в веб-приложении с простыми формами через данные доступ к данным не обязательно должен обрабатывать исключение. Он может добавить информацию к нему, если это уместно, но для такого простого приложения глобальный обработчик ошибок может позаботиться о регистрации и отображении сообщения об ошибке.
Следует также отметить (я предполагаю, что вы говорите о .NET здесь), что блок try не обязательно должен всегда сопровождаться блоком catch. Вы можете try{}finally{} позаботиться об очистке после исключения (например, изящного закрытия внешнего ресурса), не удосужившись перехватить исключение и вместо этого позволить ему всплыть соответствующим образом.