Это хорошая практика, чтобы поймать проверенное исключение и выдать RuntimeException?

70

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

RoflcoptrException
источник
17
«Цена проверяемых исключений является нарушением принципа« открытый / закрытый принцип ». Если вы бросили проверенное исключение из метода в своем коде, а улов на три уровня выше, вы должны объявить это исключение в сигнатуре каждого метода между вами и уловом. Это означает, что изменение на низком уровне программного обеспечения может вызвать изменения подписи на многих более высоких уровнях ». —Роберт К. Мартин, «Чистый код», стр. 107
Сонго
6
Интересно отметить, что Джим Уолдо противостоит непроверенным исключениям в магазине «Java: The Good Parts» shop.oreilly.com/product/9780596803742.do, говоря, что взрослые программисты должны генерировать только проверенные исключения. Мы прочитали это в нашем кувшине только 6 лет назад, когда он вышел, и это казалось хорошим советом! Теперь, с функциональным программированием, проверенные исключения абсолютно громоздки. Такие языки, как Скала и Котлин, даже не имеют их. Я также начал проверять не проверенные исключения.
ГленПетерсон
@GlenPeterson У вас также есть совет в FP, чтобы вообще избегать исключений и использовать вместо этого типы сумм
jk.
Там также очевидный случай функциональных интерфейсов: предопределённые функциональные интерфейсы (то есть Function, Predicateи т.д.) не имеют параметризованные броски положения. Это означает, что вам нужно перехватывать, переносить и перебрасывать любые проверенные исключения во внутреннем цикле любых методов stream (). Это само по себе помогает мне понять, являются ли проверенные исключения плохой идеей.
Джоэл Корнетт
Нет ничего плохого в создании пользовательских подклассов RuntimeException для передачи значения через ваше исключение.
Джоэл Корнетт

Ответы:

55

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

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

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

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

c_maker
источник
17
В большинстве реальных приложений существует очень мало неисправимых условий. Почти всегда был какой-то уровень, на котором вы можете и должны сказать: «Хорошо, это действие не выполнено, поэтому мы показываем / регистрируем красивое сообщение об ошибке и продолжаем / ждем следующего».
Майкл Боргвардт
6
Это правда, @MichaelBorgwardt, но место для такого рода обработки часто находится на самом высоком уровне приложения, поэтому всякий раз, когда я вижу, как разработчики "обрабатывают" исключения на более низких уровнях, обычно легко удалить их обработку и просто фильтровать исключение. вверх. Например, веб-инфраструктура, такая как JSF, перехватывает исключения на самом высоком уровне, печатает сообщения журнала и продолжает обрабатывать другие запросы (не говоря о том, что обработка по умолчанию подходит, просто пример).
DavidS
40

Это может быть ХОРОШО . Пожалуйста, прочитайте:

http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html

В большинстве случаев клиентский код не может ничего сделать с SQLExceptions. Не стесняйтесь конвертировать их в непроверенные исключения. Рассмотрим следующий фрагмент кода:

public void dataAccessCode(){
  try{
      ..some code that throws SQLException
  }catch(SQLException ex){
      ex.printStacktrace();
  }
} 

Этот блок catch просто подавляет исключение и ничего не делает. Обоснование заключается в том, что мой клиент ничего не может сделать с SQLException. Как насчет этого следующим образом?

public void dataAccessCode(){
   try{
       ..some code that throws SQLException
   }catch(SQLException ex){
       throw new RuntimeException(ex);
   }
} 

Это преобразует SQLException в RuntimeException. Если возникает SQLException, предложение catch генерирует новое RuntimeException. Поток выполнения приостанавливается, и сообщается об исключении. Тем не менее, я не повреждаю свой уровень бизнес-объектов ненужной обработкой исключений, тем более что он ничего не может сделать с SQLException. Если моему улову нужна основная причина исключения, я могу использовать метод getCause (), доступный во всех классах исключений, начиная с JDK1.4.

Бросать проверенные исключения и неспособность восстановиться после этого не помогает.

Некоторые люди даже думают, что проверенные исключения не должны использоваться вообще. См. Http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html.

Недавно несколько авторитетных экспертов, включая Брюса Экеля и Рода Джонсона, публично заявили, что, хотя они изначально полностью согласились с ортодоксальной позицией в отношении проверяемых исключений, они пришли к выводу, что исключительное использование проверенных исключений не так уж и хорошая идея, как появились сначала, и именно проверенные исключения стали значительным источником проблем для многих крупных проектов. Экель придерживается более крайнего взгляда, предлагая исключить все исключения; Взгляд Джонсона является более консервативным, но все же предполагает, что ортодоксальное предпочтение проверенных исключений чрезмерно. (Стоит отметить, что архитекторы C #, которые почти наверняка имели большой опыт использования технологии Java, предпочли исключить проверенные исключения из языкового дизайна, делая все исключения непроверенными исключениями.

Также по той же ссылке:

Решение использовать непроверенные исключения является сложным, и ясно, что нет очевидного ответа. Совет Sun - использовать их даром, подход C # (с которым согласны Экель и другие) - использовать их для всего. Другие говорят: «Есть золотая середина».

mrmuggles
источник
13

Нет, вы не ошиблись. Его практика крайне ошибочна. Вы должны выдать исключение, которое фиксирует проблему, вызвавшую его. RunTimeException является широким и исчерпывающим. Это должно быть NullPointerException, ArgumentException и т. Д. Независимо от того, что точно описывает, что пошло не так. Это дает возможность дифференцировать проблемы, которые вы должны решить, и позволить программе выживать в сравнении с ошибками, которые должны быть в сценарии «Не проходить». То, что он делает, лишь немного лучше, чем «При ошибке продолжить далее», если в информации, представленной в вопросе, чего-то не хватает.

установка
источник
1
Спасибо за подсказку. А что если он сгенерирует пользовательское исключение, которое он реализовал, которое наследует непосредственно от RuntimeException?
RoflcoptrException
27
@Gary Buyn: многие люди считают, что проверенное исключение является неудачным экспериментом по проектированию языка, и именно их следует использовать экономно, а не по привычке.
Майкл Боргвардт
7
@Gary Buyn: Вот статья, которая довольно хорошо описывает дебаты: ibm.com/developerworks/java/library/j-jtp05254/index.html Также обратите внимание, что через 15 лет после того, как Java представила эту функцию, ни один другой язык не принял ее, и C ++ устарел аналогичную функцию.
Майкл Боргвардт
7
@c_maker: На самом деле, Блох в основном продвигает ортодоксальную точку зрения, и, похоже, ваш комментарий в основном касается использования большего количества исключений, точка. Я считаю, что единственная действительная причина использовать проверенное исключение - это условие, которое, как вы ожидаете, будет немедленно обработано всеми вызывающими.
Майкл Боргвардт
14
Ненужное выбрасывание проверенных исключений нарушает инкапсуляцию. Что вы делаете, если простой метод, такой как getAccounts (), выдает вам SQLException, NullPointerException или FileNotFoundException? Ты справишься с этим? Возможно, вы просто «поймаете (исключение e) {}». Кроме того, эти исключения - специфическая его реализация! Это не должно быть частью договора! Все, что вам нужно знать, это то, что произошла ошибка . А что если реализация изменится? Внезапно все должно измениться, потому что метод больше не выдает «SQLException», а вместо этого «ParseXMLException»!
KL
8

По-разному.

Эта практика может быть даже мудрой . Существует много ситуаций (например, при веб-разработке), когда, если возникает какое-то исключение, вы не можете ничего сделать (потому что вы не можете, например, восстановить несогласованную БД из своего кода :-), это может сделать только разработчик). В этих ситуациях целесообразно превратить выброшенное исключение в исключение времени выполнения и перебросить его. Чем вы можете перехватить все эти исключения в каком-либо слое обработки исключений, зарегистрировать ошибку и отобразить пользователю какой-нибудь красивый локализованный код ошибки + сообщение.

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

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

malejpavouk
источник
Вы надеетесь, что разработчик API знал, что он делает, и хорошо использовал проверенные исключения. Я начал видеть API, которые предпочитают выбрасывать исключения во время выполнения, а также документировать их, чтобы у клиента была возможность перехватить его, если он этого хочет.
c_maker
Метод, который выдает исключение, обычно не может знать, может ли вызывающая сторона восстановиться после него. С другой стороны, я хотел бы предложить, чтобы метод позволял сбрасывать только проверенное исключение, выданное внутренним методом, если знает, почему внутренний метод вызвал исключение, и причина соответствует API внешнего метода. Если внутренний метод неожиданно выдает проверенное исключение, то, если оно всплывет как проверенное исключение, это может привести к тому, что вызывающая сторона будет дезинформирована о том, что произошло.
суперкат
2
Спасибо за упоминание exception handling layer- например, в веб-приложении, фильтра.
Джейк Торонто
5

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

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

Предполагая, что RuntimeException позже не перехватывается и не игнорируется, его нет рядом с OnErrorResumeNext.

OnErrorResumeNext возникает, когда кто-то перехватывает исключение и просто игнорирует его или просто распечатывает. Это ужасно плохая практика почти во всех случаях.

user606723
источник
Это может иметь место в верхней части дерева вызовов, где единственное, что вы можете сделать, это попытаться изящно восстановиться, и зная, что конкретная ошибка действительно не поможет. В этом случае вам может потребоваться записать ошибку и двигаться дальше (обработать следующую запись, сообщить пользователю, что произошла ошибка и т. Д.). В противном случае нет. Вы должны всегда обрабатывать исключения настолько близко к ошибке, насколько это практически возможно, а не заключать их в белый слон для следующего обработчика.
Майкл К
@MichaelK Проблема «настолько близка к ошибке, насколько это практически возможно», на практике часто означает «через несколько промежуточных слоев, которые находятся вне вашего прямого контроля». Например, если мой класс должен реализовать определенный интерфейс, мои руки связаны. Это может произойти как угодно глубоко в дереве вызовов. Даже когда интерфейсы находятся под моим контролем, добавление объявлений throws может привести к утечке абстракции, если существует только ограниченный набор конкретных реализаций, которые могут предположительно генерировать throw. Заставить каждого клиента оплачивать стоимость реализации нескольких деталей - не лучший компромисс в дизайне IMO.
Тим Сегин
4

TL; DR

посылка

  • Исключения времени выполнения должны создаваться, когда ошибка неустранима: когда ошибка находится в коде и не зависит от внешнего состояния (таким образом, восстановление будет исправлять код).
  • Проверенные исключения должны генерироваться, когда код верен, но внешнее состояние не соответствует ожидаемому: нет сетевого подключения, файл не найден или поврежден и т. Д.

Заключение

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


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

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

Например, целесообразно выдать исключение времени выполнения для следующего:

float nan = 1/0;

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

Или, например, вот часть HashMapконструктора:

public HashMap(int initialCapacity, float loadFactor) {
    if (initialCapacity < 0)
        throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity);
    if (initialCapacity > MAXIMUM_CAPACITY)
        initialCapacity = MAXIMUM_CAPACITY;
    if (loadFactor <= 0 || Float.isNaN(loadFactor))
        throw new IllegalArgumentException("Illegal load factor: " +
                loadFactor);
    // more irrelevant code...
}

Чтобы зафиксировать начальную емкость или коэффициент загрузки, целесообразно отредактировать код, чтобы убедиться, что в него передаются правильные значения. Это не зависит от того, работает ли какой-нибудь удаленный сервер, от текущего состояния диска, файл или другая программа. То, что конструктор вызывается с недопустимыми аргументами, зависит от правильности вызывающего кода, будь то неправильное вычисление, которое привело к неверным параметрам или неуместному потоку, который пропустил ошибку.

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

Теперь слово «выздоровление» здесь может быть хитрым. Это может означать, что вы найдете другой способ достижения цели: например, если сервер не отвечает, вам следует попробовать следующий сервер. Если такое восстановление возможно для вашего случая, то это замечательно, но это не единственное, что означает восстановление - восстановление может просто отображать диалоговое окно с сообщением об ошибке, объясняющее, что произошло, или, если это серверное приложение, то это может быть отправив электронное письмо администратору или даже просто записав ошибку надлежащим образом и кратко.

Давайте возьмем пример, который был упомянут в ответе mrmuggles:

public void dataAccessCode(){
   try{
       ..some code that throws SQLException
   }catch(SQLException ex){
       throw new RuntimeException(ex);
   }
}

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

public Data dataAccessCode() throws SQLException {
    // some code that communicates with the database
}

Что учитывает возможность восстановления абонентом:

public void loadDataAndShowUi() {
    try {
        Data data = dataAccessCode();
        showUiForData(data);
    } catch(SQLException e) {
        // Recover by showing an error alert dialog
        showCantLoadDataErrorDialog();
    }
}

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

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

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


Учитывая вышесказанное, когда уместно выбрасывать проверенное исключение как RuntimeException? Когда используемый вами код предполагает зависимость от внешнего состояния, но вы можете четко утверждать, что он не зависит от внешнего состояния.

Учтите следующее:

StringReader sr = new StringReader("{\"test\":\"test\"}");
try {
    doesSomethingWithReader(sr); // calls #read, so propagates IOException
} catch (IOException e) {
    throw new IllegalStateException(e);
}

В этом примере код распространяется, IOExceptionпотому что API Readerпредназначен для доступа к внешнему состоянию, однако мы знаем, что StringReaderреализация не имеет доступа к внешнему состоянию. В этой области, где мы, безусловно, можем утверждать, что части, участвующие в вызове, не обращаются к IO или любому другому внешнему состоянию, мы можем безопасно перевести исключение в качестве исключения времени выполнения без удивительных коллег, которые не знают о нашей реализации (и, возможно, при условии, что код доступа к IO выдает IOException).


Причина строгой проверки внешних зависимых от состояния исключений заключается в том, что они недетерминированы (в отличие от логически зависимых исключений, которые будут предсказуемо воспроизводиться каждый раз для версии кода). Например, если вы попытаетесь разделить на 0, вы всегда получите исключение. Если вы не разделите на 0, вы никогда не создадите исключение, и вам не нужно обрабатывать этот случай исключения, потому что это никогда не произойдет. В случае доступа к файлу, однако, одноразовое выполнение не означает, что вы добьетесь успеха в следующий раз - пользователь мог изменить разрешения, другой процесс мог удалить или изменить его. Таким образом, вы всегда должны обрабатывать этот исключительный случай, или у вас, вероятно, есть ошибка.

Бен Баркай
источник
2

Для автономных приложений. Когда вы знаете, что ваше приложение не может обработать исключение, вы могли бы вместо того, чтобы выдавать проверенное RuntimeException, генерировать Error, позволить аварийному завершению приложения, надеяться на сообщения об ошибках и исправлять ваше приложение. (См ответ на mrmuggles для более глубокого обсуждения про и против сдаваемого против бесконтрольно.)

Каспер ван ден Берг
источник
2

Это обычная практика во многих рамках. Например Hibernate, именно это. Идея состоит в том, что API не должны быть навязчивыми для клиентской стороны и Exceptionнавязчивыми, поскольку вы должны явно написать код для обработки их в том месте, где вы вызываете API. Но это место может быть не лучшим местом для обработки исключения в первую очередь.
На самом деле, если честно, это «горячая» тема, и многие спорят, поэтому я не буду принимать сторону, но скажу, что то, что делает / предлагает ваш друг, не является чем-то необычным или необычным.

user10326
источник
1

Вся вещь с «проверенным исключением» - плохая идея.

Структурное программирование позволяет передавать информацию только между функциями (или, на языке Java, методами), когда они «рядом». Точнее говоря, информация может перемещаться между функциями только двумя способами:

  1. От вызывающего к вызываемому через передачу аргументов.

  2. От вызываемого до вызывающего, в качестве возвращаемых значений.

Это принципиально хорошая вещь. Это то, что позволяет вам рассуждать о вашем коде локально: если вам нужно понять или изменить часть вашей программы, вам нужно только взглянуть на эту часть и другие «близлежащие».

Однако в некоторых обстоятельствах необходимо отправлять информацию в «отдаленную» функцию, чтобы никому из «посредников» не было «известно». Именно тогда должны быть использованы исключения. Исключением является секретное сообщение, отправляемое от сборщика (любая часть вашего кода может содержать throwинструкцию) обработчику (любая часть вашего кода может содержать catchблок, совместимый с исключением, которое было thrown).

Проверенные исключения разрушают секретность механизма, а вместе с ним и саму причину его существования. Если функция может позволить своему вызывающему «знать» часть информации, просто отправьте эту часть информации непосредственно как часть возвращаемого значения.

Пен
источник
Было бы полезно упомянуть, что проблема такого рода может привести к хаосу в тех случаях, когда метод запускает функцию, предоставляемую вызывающей стороной. У автора метода, получающего функцию, во многих случаях не будет причин знать, и не заботиться о том, что ожидает вызывающий объект, и каких исключений может ожидать вызывающий объект. Если код, получающий метод, не ожидает, что он выдаст проверенное исключение, предоставляемому методу, возможно, придется обернуть любые проверенные исключения, которые он будет выдавать, в непроверенные исключения, которые его поставщик может затем перехватить.
суперкат
0

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

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

Например, Integer.parseInt (String) принимает строку и возвращает ее целочисленный эквивалент и выдает исключение NumberFormatException, если строка не является числовой. Теперь представьте, что отправка формы с полем ageпреобразуется с помощью этого метода, но клиент уже обеспечил бы проверку со своей стороны, поэтому нет смысла принудительно проверять исключение.

user94369
источник
0

Здесь действительно есть пара вопросов

  1. Вы должны преобразовать проверенные исключения в непроверенные?

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

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

  1. Если вы собираетесь превратить непроверенное исключение в проверенное исключение, как это сделать?

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

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

Питер Грин
источник
0

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

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

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

Допустим, ваше приложение имеет следующие уровни снизу вверх: NET, TCP, HTTP, REST, DATA MODEL, BUSINESS.

Если ваш бизнес-уровень хочет выполнить вызов покоя ... подождите секунду. Почему я это сказал? Почему я не произнес HTTP-запрос, TCP-транзакцию или отправил сетевые пакеты? Потому что они не имеют отношения к моему бизнесу. Я не собираюсь обращаться с ними, я не собираюсь смотреть на их детали. Я совершенно в порядке, если они глубоко в исключения, которые я получаю в качестве причины, и я не хочу знать, что они даже существуют.

Более того, это плохо, если я знаю детали, потому что если завтра я хочу изменить подчеркивающие транспортные протоколы, относящиеся к деталям, которые являются специфическими для протокола TCP, это означает, что моя абстракция REST не сделала хорошую работу, чтобы абстрагироваться от конкретная реализация.

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

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

GSF
источник
-2

По моему мнению,

На уровне фреймворка мы должны отлавливать исключения во время выполнения, чтобы уменьшить количество блоков try catch для вызывающего в том же месте.

На уровне приложений мы редко фиксируем исключения во время выполнения, и я думаю, что эта практика была плохой.

Марк Се
источник
1
И что вы будете делать с этими исключениями на уровне структуры?
Матье
Если в платформе есть слой пользовательского интерфейса, который может обрабатывать исключения, то пользовательский интерфейс отображает сообщение об ошибке какого-то рода, что что-то пошло не так. В случае одностраничного приложения javascript приложение может отобразить сообщение об ошибке. Конечно, уровень пользовательского интерфейса должен обрабатывать ошибку, только если более глубокий уровень действительно не может восстановиться после ошибки.
Джейк Торонто