Java: проверено против непроверенного объяснения исключения

является ли что-то "проверенным исключением", не имеет никакого отношения к тому, поймаете ли вы его или что вы делаете в блоке catch. Это свойство классов исключений. Все, что является наследником Exceptionза исключением на RuntimeException и его подклассы являются проверенным исключением.

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

почему они позволяют пузырь исключения вверх? Не обрабатывать ошибку, чем раньше лучше? Почему пузыри вверх?

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

1. выше рассмотрите проверенное исключение? Нет Тот факт, что вы обрабатываете исключение, не делает его проверенным исключением, если это исключение RuntimeException.

2. является ли RuntimeException непроверенным исключением? Да

проверенные исключения являются подклассами java.ленг.Исключение Непроверенные исключения являются подклассами java.ленг.RuntimeException

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

надеюсь, что это помогает.

Q: должен ли я пузыриться точно исключение или маскировать его с помощью исключения?

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

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

вместо этого сделайте следующее:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

съедая исходную первопричину хоронит фактическую причину вне восстановления является кошмаром для групп поддержки производства, где все они получают доступ к журналам приложений и сообщения об ошибках. Хотя последний является лучшим дизайном, но многие люди не используют его часто, потому что разработчики просто не могут передать основное сообщение вызывающему абоненту. Поэтому сделайте твердое замечание:Always pass on the actual exception назад, независимо от того, завернуты ли они в какое-либо конкретное исключение приложения.

на try-catching RuntimeExceptions

RuntimeExceptions как общее правило не должны быть try-catched. Они обычно сигнализируют об ошибке программирования и должны быть оставлены в покое. Вместо этого программист должен проверить состояние ошибки перед вызовом некоторого кода, который может привести к исключению RuntimeException. Например:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

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

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

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

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

здесь проверка ошибок перед вызовом не стоит усилий, потому что это по существу означает дублировать все код преобразования строки в целое число внутри метода parseInt () - и подвержен ошибкам, если он реализован разработчиком. Так что лучше просто покончить с try-catch.

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

1 . Если вы не уверены в исключении, проверьте API:

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

2 . Да, и каждое исключение, которое расширяет его.

3 . Нет необходимости ловить и бросать одно и то же исключение. В этом случае вы можете показать новое диалоговое окно файла.

4 . FileNotFoundException и уже проверено исключение.

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

хорошим чтением является сам документ Oracle: http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

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

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

там также важный бит информации в Спецификация Языка Java:

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

суть ИМХО в том, что вы можете поймать любой RuntimeException, но вы не обязаны и, на самом деле реализация не требуется поддерживать то же самое не проверено исключений, так как они не являются частью договора.

1) Нет, исключение NumberFormatException является непроверенным исключением. Даже если вы поймали его (вы не обязаны), он не установлен. Это связано с тем, что это подкласс IllegalArgumentException, который является подклассом RuntimeException.

2) RuntimeException является корнем всех непроверенных исключений. Каждый подкласс RuntimeException не отмечен. Все остальные исключения и Throwables проверяются за исключением ошибок (которые входят в Throwable).

3/4) можно предупредите пользователя, что они выбрали несуществующий файл и попросите новый. Или просто прекратите информировать пользователя, что они ввели что-то недопустимое.

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

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

проверено-склонны к этому. Проверено во время компиляции.

например.. FileOperations

UnChecked-из-за плохих данных. Проверено время выполнения.

например..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

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

проверенные исключения проверяются во время компиляции JVM и его связанные с ресурсами(файлы/db/stream/socket и т. д.). Мотив проверенного исключения заключается в том, что во время компиляции, если ресурсы недоступны, приложение должно определить альтернативное поведение для обработки этого в блоке catch/finally.

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

объяснение взято из http://coder2design.com/java-interview-questions/

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

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

позвольте мне показать вам пример.

давайте иметь хороший и чистый интерфейс такой

public interface IFoo {
    public void foo();
}

теперь мы можем написать много реализаций метода foo(), как эти

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

класс Foo прекрасно. Теперь давайте сделаем первую попытку в классе Bar

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

этот класс бар не будет компилироваться. Поскольку InterruptedException является проверенным исключением, вы должны либо захватить его (с помощью метода try-catch inside foo ()), либо объявить, что вы его бросаете (добавление throws InterruptedException к сигнатуре метода). Поскольку я не хочу захватывать это исключение здесь (я хочу, чтобы оно распространялось вверх, чтобы я мог правильно справиться с ним где-то еще), Давайте изменим подпись.

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

этот класс бар не будет компилироваться либо! Метод бара foo() не переопределяет метод IFoo foo (), поскольку их сигнатуры различны. Я мог бы удалить аннотацию @Override, но я хочу программировать против интерфейса IFoo like IFoo foo; и позже решить, на какой реализации я хочу использовать, как foo = new Bar();. Если метод бара foo () не переопределяет метод IFoo foo, когда я делаю foo.foo(); он не будет вызывать реализацию бара foo().

To сделайте бар public void foo() throws InterruptedException переопределить это IFoo public void foo() Я должен добавить throws InterruptedException к сигнатуре метода IFoo. Это, однако, вызовет проблемы с моим классом Foo, так как подпись метода foo() отличается от подписи метода IFoo. Кроме того, если я добавил throws InterruptedException к методу Foo foo () я бы получил еще одну ошибку, заявив, что метод Foo foo () объявляет, что он бросает InterruptedException, но он никогда не бросает InterruptedException.

как вы можете видеть (если бы я сделал достойную работу в объясняя этот материал), тот факт, что я бросаю проверенное исключение, такое как InterruptedException, заставляет меня привязать мой интерфейс IFoo к одной из его реализаций, что, в свою очередь, вызывает хаос в других реализациях IFoo!

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

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

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

Я предполагаю, что вы имеете в виду что-то вроде этого:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

нет, всегда объявляйте самые точные исключение возможно, или список таких. Исключения, которые вы объявляете свой метод способным к выбрасыванию, являются частью контракта между вашим методом и вызывающим. Метание "FileNotFoundException" означает возможно, что имя файла недопустимо, и файл не будет найден; вызывающий должен будет обрабатывать это разумно. Бросать " исключение "означает" Эй, дерьмо происходит. Сделка."Это очень плохой API.

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

• Java различает две категории исключений (проверено и снято)
• Java применяет catch или объявленное требование для проверенных исключений
исключения определяет, является ли исключение checked или unchecked.
• все типы исключений, которые являются прямыми или косвенными подклассами класса RuntimeException это исключение непроверенное.
• все классы, которые наследуют от исключения класса, но не RuntimeException являются считается проверенными исключениями.
• классы, которые наследуются от ошибки класса, считаются непроверенными.
• компилятор проверяет каждый вызов метода и замедление, чтобы определить, является ли метод выдает проверенное исключение.
  • если это так, компилятор гарантирует, что исключение будет поймано или объявлено в предложении throws.
• чтобы удовлетворить часть объявления требования catch-or-declare, метод, который генерирует исключение должно быть предоставьте предложение throws, содержащее проверенное исключение.
• классы исключений определяются для проверки, когда они считаются достаточно важными, чтобы поймать или объявить.

почему они позволяют исключение пузыриться? Не лучше ли обрабатывать ошибку раньше? Почему пузыри вверх?

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

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

мой абсолютный фаворит описание разницы между непроверенными и проверенными исключениями предоставляется в статье Java Tutorial trail,"непроверенные исключения-полемика" (извините, что все элементарно на этом посту - но, эй, основы иногда самые лучшие):

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

сердце "какого типа исключения бросать" является семантическим (в некоторой степени), и приведенная выше цитата обеспечивает и отличное руководство (следовательно, я все еще поражен тем, что C# избавился от проверенных исключений - особенно поскольку Лисков утверждает их полезность).

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

Исключения Времени Выполнения Исключения среды выполнения называются непроверенными исключениями. Все остальные исключения проверяются исключения, и они не являются производными от java.ленг.RuntimeException.

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

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

вот простое правило, которое поможет вам решить. Это связано с тем, как интерфейсы используются в Java.

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

посмотрите на методы интерфейса и рассмотрите исключения, которые они могут бросок:

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

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

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

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

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

подробнее о проверенных и непроверенных исключениях читайте здесь http://learnjava.сегодня/2015/11/checked-vs-unchecked-exceptions/

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

короче говоря, исключения, которые ваш модуль или модули выше должны обрабатывать во время выполнения, называются check-exceptions, другие не отмечены-исключения, которые либо RuntimeException или Error. В этом видео он объясняет проверенные и непроверенные исключения в java. https://www.youtube.com/watch?v=ue2pOqLaArw

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

Если кто-то заботится о еще одном доказательстве нелюбви к проверенным исключениям, см. Первые несколько абзацев популярной библиотеки JSON:

" хотя это проверенное исключение, оно редко восстанавливается. Большинство абонентов должны просто обернуть это исключение в непроверенное исключение и перестроить:"

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

http://developer.android.com/reference/org/json/JSONException.html

Проверенные Исключения:

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

• Они происходят во время компиляции.

• если они не обрабатываются должным образом, они дадут ошибку времени компиляции (не исключение).

• проверяются все подклассы класса Exception кроме RuntimeException Исключение.

  Гипотетический Пример - предположим, что вы покидаете свой дом для экзамена, но если вы проверите, взяли ли вы билет в зал Дома(время компиляции), то в экзаменационном зале(время выполнения) не будет никаких проблем.

Исключение Непроверенное:

• исключения, которые не проверяются компилятором, называются непроверенными исключениями.

• Это происходит во время выполнения.

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

• все подклассы RunTimeException и Error являются непроверенными исключениями.

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

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

1. непроверенные исключения-это неограниченные gotos. И неограниченные gotos считаются плохой вещью.

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

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