Я хотел бы знать, что лучше или/и быстрее в общем программировании? Избегать исключения или ждать исключения?Что лучше/быстрее? Попробовать или избежать исключения?
Избегайте исключение будет:
string a = null;
list = someMethod();
if(list.Length > 0){
a = list[0];
}
if(a!=null) ...
Или попробуйте поймать исключение ...
string a = null;
try{
a = someMethod()[0];
catch{}
if(a!=null) ...
Производительность здесь не самая важная проблема. Вопрос в том, какой из двух приводит к более читаемым/поддерживаемым/проверяемым программам. Вы можете беспокоиться о производительности позже.
В общем, не используйте исключения для управления потоком. Они эффективно являются нелокальными goto, что делает программы более трудными для чтения и наблюдения. Таким образом, они должны быть зарезервированы для исключительных ситуаций. Если вам удастся избежать использования блока управления потоком try-catch, не делайте этого. Ваши программы станут более читабельными и удобными.
«Право» способ справиться с этой ситуацией является
var list = someMethod();
if(list == null || list.Length == 0) {
// handle something bad
}
string a = list[0];
if(a != null) {
// go
}
Вы можете избежать проверки, что list не является недействительным и не пусто, если есть договор (Contract.Ensures), что гарантирует возвращаемое значение someMethod является но не пустым.
Это правда, однако, что исключения являются дорогостоящими. Независимо от того, повлияют ли они на производительность вашей программы (т. Е. Узкое место), это еще один вопрос. Но правильно используются исключения, как правило, не являются узким местом (кто заботится о производительности, когда ваша заявка терпит крах?)
Да, спасибо за ответ, я знал, что что-то не так с попыткой и пустым уловом. О программах, более обслуживаемых, очень верно. Возможно, другое исключение не ожидается, и вы никогда не узнаете. Возможно, пустой улов будет иметь смысл, если вам все равно, какое исключение может возникнуть, вы просто хотите продолжить запуск программы. – carlosdubusm
@carlosdumusm: Кажется, вы правильно понимаете это, но я хочу указать, что пустые блоки catch или блоки catch, которые улавливают все исключения (т. Е. Улавливают базовый класс «Исключение»), плохие, плохие, ПЛОХО. Вы не знаете, какой тип исключения может быть выброшен, но теперь вы заявляете, что можете обрабатывать все из них.Когда ситуация находится в плохом состоянии, но вы не знаете, как плохо или что плохое состояние, потому что вы «обрабатываете» все исключения, потенциально очень опасно продолжать, как будто ничего не произошло. Обращайтесь с тем, что, как вы знаете, можете справиться, и в противном случае быстро справляетесь. – jason
Да, имеет смысл, у меня есть несколько лет программирования, но я мало знаю об исключениях, а иногда и не знаю, где попытаться поймать или куда бросить. Благодарю. – carlosdubusm
ВСЕГДА ВСЕГДА ВСЕГДА избежать исключение, если вы можете.
Исключения должны быть исключительными.
Если вы можете предсказать его, предохраняйте его.
Люди, которые используют пустые уловах блоки, как, что должно быть запрещено использование компьютера ...
Это также быстрее, чтобы не идти в улове блоков.
Исключения стоят дорого - если вы можете протестировать и избежать исключения, сделайте это.
Исключения не должны использоваться для нормального потока программы.
Да, никогда не думал о стоимости исключений, спасибо. – carlosdubusm
Бросание исключений - дорогостоящая задача, поэтому я всегда буду стараться и проверять, а не поймать.
Это должно быть достаточно легко проверить, сгенерировать код, который генерирует исключение через каждый прогон и проверять его на аналогичный набор кода, который выполняет условную проверку и измеряет производительность.
Если код задокументирован деталями, из которых будут исключены исключения, вы должны иметь возможность адаптировать код вызова. Конечно, вы не можете обрабатывать каждый сценарий (возможно, ошибки времени выполнения на более низком уровне), поэтому ваш код должен только попробовать и обрабатывать исключения, где он может реагировать и, возможно, продолжать.
Это зависит. Я почти всегда стараюсь избегать исключения, если это не является чрезмерно дорогостоящим.
Исключения могут использоваться только для исключительных условий (если нет альтернативы), поэтому вы должны использовать только try/catch, когда происходит что-то необычное, с которым вам все еще нужно иметь дело (всплывающее сообщение об ошибке).
Наличие try/catch также сигнализирует программисту о том, что может произойти какая-то внешняя ошибка, и с этим нужно иметь дело. В вашем примере list, являющийся нулем, является просто нормальной частью потока выполнения программы/управления, и поэтому нет ничего исключительного в этом.
Кроме того, пустая уловка, как правило, является плохой вещью в любом случае (хотя существуют ограниченные ситуации, когда это необходимо). В любом случае, это обязательно должно быть комментарий, чтобы объяснить, почему вы ничего не делаете об исключениях.
Там в useful blog post о досадном исключении могут оказаться полезными
Сугубо из ряда инструкций/производительности точки над значительным N выполнением, избегая более дорогой, потому что вы проверяете длину каждый раз для каждого входа , За исключением этого, ветвь catch выполняется только в этом случае.
Но это SLOWER, когда это происходит. Он маскирует другие потенциальные ошибки. И это ужасная практика программирования. – CaffGeek
Try-Catch не несет никаких накладных расходов вообще при нормальном потоке? Тест и прыжок, используемые в примере, кажутся довольно дешевыми с точки зрения времени обработки. – Derrick
Это ужасная практика программирования, когда это пустой 'catch {}', который, как вы сказали, маскирует другие ошибки программирования. И, как уже упоминалось, исключения должны использоваться для исключительных условий, а не для чего-то, что происходит регулярно (например, если вы знаете, что список всегда будет нулевым для инициализации и ожидается, что он ударит так часто, он уже не является таким исключительным, и вы должны создать проверку для этого). – Aphex
, конечно, избегайте исключений, попробуйте поймать, приведет к снижению производительности.
Отмените слово «быстрее», это не имеет значения. И это даже не правильный способ использования try-catch, поскольку вы как бы троллируете CLR. – BoltClock
просто пример человека ... – carlosdubusm
@BoltClock, нет, это не так. Если исключение произойдет. Это медленнее. – CaffGeek