Почему попробовать блоки нужно поймать

Question

У меня есть немного кода, как такой

try 
{ 
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value; 
} catch { } 

Теперь я не знаю, до вызова этого вызова, если атрибут Ищу существует (Хороший ола Sharepoint).

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

try 
{ 
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value; 
} catch { } 
try 
{ 
    result.LastName = nodes[myIdx].Attributes["ows_LastName"].Value; 
} catch { } 

.... 

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

Почему я не мог просто сделать

try { result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value; } 

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

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

Answer 1

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

нет просто ничего исключительного, за исключением

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

Например -

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

[нет] я ничего не могу сделать (или нужно сделать), чтобы зафиксировать на поведение

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

Answer 2

Если вы хотите проглотить исключение (это, но ничего не делать), вы должны явно сделать это.

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

1. Обращайтесь с каким-либо исключением. Это может означать:

 
a. Retry 
b. Rethrow it (preserving the inner exception) with a more meaningful message. 
c. Do it another way. 
d. Log it (though logging and rethrowing might be better). 
e. Other 

2.   Просто дайте ему пузыриться (не попробовать, или просто попробовать /, наконец).

Answer 3

Блок try/catch был разработан Явно для ловли и обработки Исключения, которые выбрасываются в ваше приложение.

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

Answer 4

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

Что касается конкретного кода, на который вы ссылаетесь, не могли бы вы просто выполнить нулевую проверку до того, как попытаетесь получить доступ к индексу?

Answer 5

Это часть синтаксиса языка. Вы не можете try без по крайней мере одного catch или finally. Нет отдельного try, только try-catch, try-finally и try-catch-finally.

Это просто не имеет смысла try некоторые кода, если вы не собираетесь беспокоить обрабатывающее исключение (catch), или, по крайней мере, убедившись, что некоторые последующий код всегда работает независимо от того, что произошло (это finally).

Answer 6

Почему бы не просто проверить, нет ли предмета null?

if(nodes[myIdx].Attributes != null && 
    nodes[myIdx].Attributes["ows_FirstName"] != null) { 
    /* ... your code ... */ 
} 

Или:

if(nodes[myIdx].Attributes != null) { 
    if(nodes[myIdx].Attributes["ows_FirstName"] != null) { 
     /* ... your code ... */ 
    } 
    if(nodes[myIdx].Attributes["ows_LastName"] != null) { 
     /* ... your code ... */ 
    } 
} 

Answer 7

Это в значительной степени был дан ответ на этот вопрос: C#: should all exceptions be caught

В принципе, если вы поймать его, то вы должны сделать что-то с ним, в противном случае Dont поймать Это. В вашем случае, почему вы не можете проверить, существует ли значение атрибута в первую очередь?

Answer 8

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

try 
{ 
    newstring = oldString.ToString(); 
} 
catch{} 

, что вы должны сделать, это:

if(oldString != null) 
{ 
    newstring = oldString; 
} 

Помните, что попытка поймать для обработки вещи, названные как «исключение»

Answer 9

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

Напоминает классический ASP On Error Resume Next

Answer 10

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

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