Предотвращение исключений по сравнению с ловлей исключений в [закрытом] Java

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

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

There are three kinds of exceptions.

Runtime exceptions are always preventable. You just have to program correctly.

Checked exceptions should be transformed to the right level of abstraction if possible ( not throw a SQLException to the user if he doesn't know/care about SQL exceptions ) or handled at the higher level ( that is, let them pop up ) and display/log proper message.

Errors should not be handled at all.

_{See the link for more details on how to prevent RuntimeExceptions}

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

Не следует проверять (foo! = Null) везде, проверяйте только то, где foo используется впервые. После этого просто используйте foo без проверки. Если foo внезапно становится нулевым после того, как вы убедились, что он не нулевой, у вас большие проблемы. Тогда уместно исключение.

try {
   foo();
}
catch (FooException e) {
}

- плохой запах кода, и его следует избегать

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

Избегайте тех, которые вы можете (NullPointerExceptions, NullReferenceExceptions и т. Д.).

Поймайте те, которые немного сложнее поймать (Ошибки Sql ... где они могут быть контроль, но вам нужно аккуратно убрать за ними). ​​

В общем, если это разумно, вы должны в первую очередь попытаться предотвратить возникновение исключения. Довольно часто это неразумно или, возможно, категорически невозможно (особенно когда дело касается io), но именно для этого и предназначены try / catch. В частности, это означает, что вы всегда должны проверять свои указатели и индексы массива, чтобы предотвратить исключение NullPointerException и ArrayIndexOutOfBoundsException. Если, конечно, вы ничего не можете с этим поделать, и вам все равно придется выбросить его заново.

I want all of my exceptions to travel upwards unless they are minor then I will swallow them (ex: prevent a claim entry dieing because an email notification function generated a NPE... I would like to swallow that NPE and keep trucking on as long as the real meat of the program throws no exceptions).

I use this method to force most of Java's unrecoverable yet checked exceptions:

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

you should catch all exceptions you can. NullPointerExceptions can always be prevented with a simple if statement. some other exceptions, like most IOExceptions, are hard to be prevented. and besides the boilerplate needed to use a try/catch block, if your class throws an exception, an object of that exception will be created and it must be garbage collected... so by not throwing exceptions, you also make your VM healthier.

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

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

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

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

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

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

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

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

class Foo {
  static BufferedReader in=new BufferedReader(new InputStreamReader(System.in));
  int getInt() throws IOException {
    int r=0;
    for(;;) {
      String s=in.readLine();
      try {
        r=Integer.parseInt(s);
        break;
      }
      catch(NumberFormatException e) {
        System.out.println("Please enter a valid integer.");
      }
    }
    return r;
  }
}

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