Блог

В настоящее время я пишу Java-оболочку для RESTful web services API.

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

Если у меня есть метод (соединение), который содержит код, который может генерировать исключения, как мне заставить эти исключения всплывать до конечного программиста? и это вообще тот способ, которым я должен это обрабатывать, в зависимости от того, как они перехватывают исключения? и т.д…

Я предлагаю вам перехватывать исключения из базового API (если только их действительно не имеет смысла пропускать) и создавать новое исключение, которое больше подходит для вашего уровня абстракции.

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

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

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

Вам в любом случае придется передать исключение пользователю, поскольку это библиотека.

• Если вы не ведете журнал и не планируете создавать пользовательские исключения, то вам просто не нужно обрабатывать исключение.
• если вы ведете журнал, обработайте исключение и повторно создайте исключение.
• если у вас есть пользовательские исключения, убедитесь, что в нем есть параметр конструктора take exception, а затем свяжите текущее исключение с вашим текущим исключением и затем создайте пользовательское исключение. Это требуется для сохранения полезной информации трассировки стека.

Вопрос в том, насколько непрозрачной вы хотите видеть свою библиотеку.

Каждый тип исключения, который вы предоставляете своим пользователям, должен подразумевать, что пользователь может что-то с этим сделать. Например,

 catch (ConnectionException e) {
  disconnect();
  connectAgain();
}
  

работает, только если у ваших пользователей есть доступ к disconnect() и connectAgain(). Однако, если вы обещаете обеспечить все виды подключения, в вашем коде уже должна быть эта логика, и если это не удается, создайте универсальное исключение WrapperException и покончите с этим.

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

Я думаю, важно, что делает API и в каком контексте он используется.

Если API является частью вашего уровня презентации / рендеринга, то я бы предпочел всегда возвращать что-то, что готово к рендерингу, оформлению или записи в поток ответов.

Если API предназначен для выполнения обработки (не связанной с рендерингом / пользовательским интерфейсом), у меня не возникло бы проблем с созданием любых исключений, выходящих за рамки логики API.

Если API спроектирован хорошо, это были бы причины, которые явно находятся вне контроля API или логически выходят за рамки того, что API «знает, как» или «должен» обрабатывать, даже если бы он мог перехватывать / контролировать это.

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

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

всего лишь мои 2 цента 🙂