Существуют руководящие принципы при разработке того, что и когда следует создавать исключения, и два соответствующих для этого сценария:
- Бросить исключения, соответствующие абстракции (т.е. парадигма перевода исключений)
- Брось исключения по возможности раньше
Способ, которым вы переводите StoreException
на MultipleCauseException
, кажется мне разумным, хотя объединение различных типов исключений в одну может быть не самой лучшей идеей. К сожалению, Java не поддерживает общие Throwable
s, поэтому, возможно, единственной альтернативой является создание отдельного подкласса MultipleStoreException
.
Что касается того, чтобы генерировать исключения как можно раньше (чего вы НЕ делаете), я скажу, что в некоторых случаях можно нарушать правило. Я чувствую, что опасность отсрочки броска заключается в том, что исключительные ситуации впадают в цепную реакцию без необходимости. По возможности вы должны избегать этого и локализовать исключение в наименьшей возможной области.
В вашем случае, если имеет смысл концептуально представить хранение ресурсов как несколько независимых задач , тогда, возможно, можно «обработать» исключение так, как вы это делали. Однако в других ситуациях, когда задачи имеют более сложные взаимосвязи взаимозависимостей, объединение их воедино усложнит задачу анализа исключений.
В более абстрактном смысле, с точки зрения теории графов, я думаю, что можно объединить узел с несколькими бездетными детьми в один. Вероятно, нехорошо объединять целое большое поддерево или, что еще хуже, циклический граф в один узел.