Почему неправильно думать, что «исключение связано с тем, как часто что-то происходит»? - PullRequest
0 голосов
/ 10 февраля 2020

Я встретил следующую выдержку в CLR через C# книгу:

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

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

Я не могу понять две вещи, которые намеревался объяснить отрывок (из моего pov). Что это значит, что an exception is related to how frequently something happens? Как можно доказать, что это неправильный способ мышления (я полагаю, что контрпример выполняет работу по доказательству этого, но все же я не понимаю контрпример, представленный в приведенном выше отрывке)?

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

1 Ответ

2 голосов
/ 11 февраля 2020

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

Очевидная причина не гадать, что они могут ошибаться. Более фундаментальная причина заключается в том, что исключения не обязательно являются редкими, в зависимости от сферы деятельности. Рассмотрим сайт электронной коммерции, где пользователи вводят номера кредитных карт. Пользователи будут часто вводить номера своих карт неправильно. Если мы связываем исключения с тем, как часто что-то происходит, мы можем определить, что неправильное число CC является , а не исключением, поскольку это происходит довольно часто.

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

Связанный: Избегайте индикаторов ошибок внутри полосы .

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