Разбор с TryParse или Parse, когда данные теоретически всегда верны - PullRequest
2 голосов
/ 30 ноября 2011

Я посмотрел на несколько других вопросов (особенно Производительность синтаксического анализа (If, TryParse, Try-Catch) ) и обдумывал ответы.Является ли злоупотребление обработкой исключений, если исключение не должно создаваться?Разве не в этом весь смысл?Поймать ошибку в том редком случае, если что-то идет не так?

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

Редактировать Я, вероятно, буду использовать Linq для XML, но вопрос все еще стоит.

Ответы [ 2 ]

2 голосов
/ 30 ноября 2011

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

Если данные могут быть (скажем) целыми числами, тогда TryParse предпочтительнее, чем Parse + catch.

С LINQ-to-XML: not parse; вместо этого используйте предоставленные операторы статического преобразования; так что вместо:

...
select int.Parse(node.Value);

Вы должны использовать

...
select(int) node;

это еще более важно для таких вещей, как DateTime, поскольку учитывает стандартные форматы XML. Он также делает «ожидаемую» вещь, если узел не существует (то есть node равен null):

select (int?)node;

вернет значение null вместо броска NullReferenceException (что и сделает node.Value). Для большинства ожидаемых типов данных существуют операторы статического преобразования.

0 голосов
/ 30 ноября 2011

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

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

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

...