Этот вид исключения Java, разрабатывают плохую практику?
Это считают плохой практикой, чтобы иметь несколько попытка в одном методе и структурировать код как это?
public void whatever() {
try {
methodThatMayThrowIOException();
} catch(IOException io) {
// do something with exception here
}
// do more stuff here that won't throw exceptions
try {
methodThatMayThrowCustomException();
} catch(CustomException ce) {
// do something with custom exception here
}
}
10 ответов
Ваш код выглядит так, как будто вы хотите выполнить часть 1 (и разрешить, перехватывая IOException , если необходимо), выполнить часть без исключений, а затем выполнить methodThatMayThrowCustomException . Ваш код в буквальном смысле не может быть написан каким-либо другим способом и сохранит ту же функциональность. Это преувеличение, но любая другая версия была бы другой в поверхностном смысле.
Это не то же самое:
public void whatever {
try {
methodThatMayThrowIOException();
// do more stuff here that won't throw exceptions
methodThatMayThrowCustomException();
} catch(IOException io) {
// do something with io exception here
} catch(CustomException ce) {
// do something with custom exception here
}
}
и способ его выполнения, если возникнет какое-либо исключение, совершенно другой. Если вам нужно последовательно восстановиться из Части 1, в любом случае нажмите Часть 2 , а затем переходите к Части 3, вы действительно не сможете написать свой код каким-либо другим способом.
Нет ничего плохого в наличии двух блоков catch, хотя смешивание того, что вызывает IOException, с тем, что вызывает CustomException, может указывать на смешение проблем, что затрудняет понимание вашего кода. Но на самом деле это не просто так, это единственный способ делать то, что вы делаете.
Я не понимаю, почему это было бы плохой практикой, пока вы действительно делаете что-то полезное с теми исключениями, которые вы поймали.
-121--3545545-Если метод может продолжить выполнение, без каких-либо проблем, даже если возникает указанное исключение, это должно быть нормально.
В случае, когда исключение должно вызвать проблемы дальше вниз по линии метода, я хотел бы, чтобы он пузырь вверх.
Выглядит нормально, но это зависит от того, что делают methodThatMayThrowIOException и methodThatMayThrowCustomException и должен ли отказ первого (methodThatMayThrowIOException) привести к отказу всего метода whatever.
Это действительно зависит от того, что вы планируете делать, если возникнет IOException. Ваш стиль позволяет вам делать больше вещей, но если вы на самом деле не планируете этим воспользоваться, то это намерение станет намного яснее, если использовать стандартную идиому.
public void whatever {
try {
methodThatMayThrowIOException();
// do more stuff here that won't throw exceptions
methodThatMayThrowCustomException();
} catch(IOException io) {
// do something with io exception here
} catch(CustomException ce) {
// do something with custom exception here
}
}
Здесь вы можете быстро понять, что если брошен IOException, то вы делаете только то, что находится внутри блока catch, и не более того.
С этим нет проблем, AFAICS. Тем не менее, 2 попытки в методе колют мне в глаза. Если вы чувствуете то же самое, я предлагаю вам правильно его реорганизовать.
ну, это зависит от того, чего вы пытаетесь достичь. обычно вы заключаете блок кода в один блок try-catch, если блок кода должен выполняться как блок, или не включать его вообще, если возникает какое-либо исключение. если это не так, то я считаю, что гораздо лучше изолировать разные блоки кода, генерирующие разные исключения в разные блоки try-catch, сэндвич «делайте здесь больше вещей, которые не генерируют исключения». просто мысль!
Нет. Это довольно хорошая практика, чтобы сузить область, в которой возникают какие-то исключения. Я часто делал это в своем коде.
Однако, если вы уверены, что в одном блоке try ... catch определенный вид исключения будет выдан только уникальной функцией, размещение их в том же блоке try тоже нормально.
Я не понимаю, почему это будет плохой практикой, если вы действительно делаете что-то полезное с исключениями, которые вы поймали.
Нет, это не так. Это хороший момент, чтобы поймать определенные исключения, когда они могут быть сгенерированы, imho, это определенно лучше, чем это:
public void whatever {
try {
methodThatMayThrowIOException();
// do more stuff here that won't throw exceptions
methodThatMayThrowCustomException();
} catch(ParentException e) {
// do something with custom exception here
}
}
Лично я думаю, что это выглядит загроможденным. Я предпочитаю иметь только одну попытку с таким количеством блоков catch, сколько мне нужно. Мне все равно, или несколько последовательностей try / catch в одном методе.