Это зависит от того, хотите ли вы, чтобы класс или другая часть приложения, использующего его, обрабатывали исключение и делали все, что требуется.
Поскольку в коде будет использоваться loadCatalog()
вероятно, не будет знать, что делать с файловым вводом-выводом или исключением формата, лично я бы пошел с созданием исключения, подобного CatalogLoadException
, и бросил бы его из метода loadCatalog (), и поместил бы вызывает исключение (FileNotFoundException
, IOException
, DataFormatException
) внутри него, включая информационное сообщение в зависимости от того, какое исключение было вызвано.
try {
...
//do this for exceptions you are interested in.
} catch(Exception e) {
//maybe do some clean-up here.
throw new CatalogLoadException(e); // e is the cause.
}
Таким образом, ваш метод loadCatalog()
будет выдавать только одно единственное и значимое исключение.
Теперь код, который будет использовать loadCatalog()
, будет иметь дело только с одним исключением: CatalogLoadException
.
loadCatalog(String filename) throws CatalogLoadException
Это также позволяет вашему методу скрыть подробности его реализации , поэтому вам не нужно изменять его сигнатуру "исключения" при изменении базовой низкоуровневой структуры.Обратите внимание, что если вы измените эту подпись, каждый фрагмент кода должен будет измениться соответствующим образом, чтобы иметь дело с введенными вами новыми типами исключений.
См. Также этот вопрос по Перевод исключений .
Обновление требования к метанию подписи:
Если у вас есть , чтобы сохранить эту подпись, то у вас нет выбора, ноthrow
их в приложение, а не catch
их в методе loadCatalog()
, в противном случае подпись throws
будет бесполезной, поскольку мы не собираемся бросать то же исключение, которое мы только что рассмотрелис.