В Java, когда я должен создать контролируемую исключительную ситуацию, и когда это должно быть исключение на этапе выполнения? [дубликат]

Если вам не нравится использовать allCast[1], вы можете просто сделать cast.cast и избавиться от allCast:

this.movieService.getCast(id).subscribe(cast => {
  this.cast = cast;
  console.log(cast);
  this.cast = cast.cast.map(el => el.name).slice(0, 4);
  console.log(this.cast);
  });
});
93
задан Community 23 May 2017 в 12:32
поделиться

13 ответов

Существует БОЛЬШОЕ разногласие по вопросам этой темы. В моем последнем задании мы столкнулись с некоторыми реальными проблемами с Исключениями на этапе выполнения, о которых забывают, пока они не обнаружились в производстве (на agedwards.com), таким образом, мы разрешили использовать контролируемые исключительные ситуации исключительно.

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

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

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

Мой опыт говорит мне, что я получаю более высокое качество, то есть, код, который ПРОСТО РАБОТАЕТ, когда я использую контролируемые исключительные ситуации. Контролируемые исключительные ситуации могут создать помехи коду, но существуют методы для контакта с этим. Мне нравится переводить исключения при передаче границы слоя. Например, если бы я отказываюсь от своего слоя персистентности, я хотел бы преобразовать исключение SQL в исключение персистентности, так как следующий слой не должен заботиться, что я сохраняюсь к базе данных SQL, но захочу знать, не могло ли что-то быть сохранено. Другая техника, которую я использую, для создания простой иерархии исключений. Это позволяет мне написать более чистый код один слой, так как я могу поймать суперкласс, и только иметь дело с отдельными подклассами, когда он действительно имеет значение.

102
ответ дан Don Branson 24 November 2019 в 06:14
поделиться

В целом я думаю совет Joshua Bloch в , Эффективный Java лучше всего суммирует ответ на Ваш вопрос: Использование проверило ожидания на восстанавливаемые условия и исключения на этапе выполнения для программных ошибок (Объект 58 в 2-м выпуске).

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

, Но также и Объекты примечания 59: Избегают ненужного использования контролируемых исключительных ситуаций и 57: исключения Использования только для исключительных условий . Как другие указали, этот случай не может гарантировать исключение вообще. Рассмотрите возврат false (или возможно объект состояния с деталями о том, что произошло), если существует недостаточно кредита.

42
ответ дан Jonik 24 November 2019 в 06:14
поделиться

Когда использовать контролируемые исключительные ситуации? Честно? По моему скромному мнению... никогда. Я думаю, что это были приблизительно 6 лет, с тех пор как я в последний раз создал контролируемую исключительную ситуацию.

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

try {
  ...
} catch (IOException e) {
  // do nothing
}

принимая во внимание, что у меня есть бесчисленные времена написанный код как это:

try {
  ...
} catch (IOException e) {
  throw new RuntimeExceptione(e);
}

, Почему? Поскольку условие (не обязательно IOException; это - просто пример), не было восстанавливаемым, но был захлопнут мое горло так или иначе, и я часто вынуждаюсь сделать выбор между выполнением вышеупомянутого и загрязнением моего API только для распространения контролируемой исключительной ситуации полностью к вершине, где это (rightlfully) фатальный и будет зарегистрировано.

существует причина, классы помощника ДАО Spring переводят проверенный SQLException в DataAccessException непроверенный.

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

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

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

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

34
ответ дан Matt Ball 24 November 2019 в 06:14
поделиться

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

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

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

, по моему скромному мнению, резюме: Исключения == странная черная магия.

конструктивное редактирование:

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

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

less-enterprisey-suggestion-edit:

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

// ...
boolean success = transferTo(otherAccount, ONE_MILLION_DOLLARS_EXCLAMATION);

if (!success) {
  UI.showMessage("Aww shucks. You're not that rich");
  return; // or something...
} else {
  profit();
}
// ...
8
ответ дан Henrik Paul 24 November 2019 в 06:14
поделиться

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

8
ответ дан IAdapter 24 November 2019 в 06:14
поделиться

Мое чувство состоит в том, что контролируемая исключительная ситуация является полезным контрактом, который должен использоваться экономно. Классическим примером того, где я думаю контролируемая исключительная ситуация, является хорошая идея, InterruptedException. Мое чувство состоит в том, что я действительно хочу смочь остановить поток / процесс, когда я хочу, чтобы он остановился, независимо от того, сколько времени кто-то указал к Thread.sleep ().

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

В ответ на комментарий Peter: вот является использование в качестве примера InterruptedException как конкретным случаем исключения, которое должно быть обработано, и у Вас должен быть полезный обработчик по умолчанию. Вот то, что я настоятельно рекомендую, конечно, в моем реальном задании. Необходимо, по крайней мере, сделать это:

catch (InterruptedException ie) {
    Thread.currentThread().interrupt();
}

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

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

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

5
ответ дан Community 24 November 2019 в 06:14
поделиться

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

разработчики C# решили, что неконтролируемые исключения предпочтены.

Или можно следовать за C-стилем и проверить возвращаемые значения и не выдать исключения.

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

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

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

4
ответ дан duffymo 24 November 2019 в 06:14
поделиться

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

Это - известная проблема, что контролируемые исключительные ситуации злоупотребляются в Java, но это не означает, что они все плохи. Вот почему это - такой в неотъемлемой части философии Spring, например ( http://www.springsource.org/about )

3
ответ дан Yoni 24 November 2019 в 06:14
поделиться

Мое правило

  • , если операторы для ошибок бизнес-логики (как Ваш код)
  • cheched исключения для ошибок среды, где приложение может восстановиться
  • uncheched исключение для ошибок среды, где существует никакое восстановление

    1. Пример для контролируемой исключительной ситуации: Сеть снижается для приложения, которое может работать офлайн
    2. Пример для uncheched исключения: База данных снижается на веб-приложении CRUD.

существует много документации относительно предмета. Можно найти много путем просмотра Быть в спящем режиме веб-страниц, так как они изменились, все исключения В спящем режиме 2.x от проверенного до непроверенного в версии 3.x

6
ответ дан kazanaki 24 November 2019 в 06:14
поделиться

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

у Bruce Eckel, автора Взгляды в Java, есть хорошее эссе по этой теме.

3
ответ дан Jason Day 24 November 2019 в 06:14
поделиться

Я не думаю сценарий (недостаточные фонды) ордеры, бросающие Exception---, это просто не достаточно исключительно, и должно быть обработано нормальным потоком управления программы. Однако, если бы я действительно должен был выдать исключение, то я выбрал бы контролируемая исключительная ситуация , путем расширения Exception, не RuntimeException, который неконтролируем. Это вынуждает меня обработать исключение явно (я должен объявить, что это брошено или поймать его где-нибудь).

IllegalArgumentException подкласс RuntimeException, который делает его исключением непроверенным. Я только рассмотрел бы бросок этого, если у вызывающей стороны есть некоторый удобный способ определить, законны ли аргументы метода. В Вашем конкретном коде не ясно, есть ли у вызывающей стороны доступ к balance, или являются ли целый "баланс проверки и фонды передачи" атомарной операцией (если это не затем вызывающая сторона, действительно не имеет никакого удобного способа проверить аргументы).

РЕДАКТИРОВАНИЕ: Разъясненный моя позиция по броску IllegalArgumentException.

3
ответ дан Zach Scrivena 24 November 2019 в 06:14
поделиться

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

3
ответ дан surendrapanday 24 November 2019 в 06:14
поделиться

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

Если вы являетесь разработчиком API (Back-End Developer), используйте проверенные исключения, в противном случае используйте исключения времени выполнения.

Также обратите внимание, что использование исключений выполнения в некоторых ситуациях следует учитывать большую ошибку, например, если вы должны бросать исключения времени выполнения из бобов сеанса (см.: http: //m-hewedy.blogspot. COM / 2010/01 / Избегайте - Runtimeexception - from.html Для получения дополнительной информации о проблеме с использованием тревоги выполнения в сессионном бобах).

2
ответ дан 24 November 2019 в 06:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: