Здравствуйте, AnonThisTime, Вы писали:

ATT>и в случае ошибки валят исключение, которое ловится глобальным уловителем (и показывается юзверю) либо вызывающим методом;
А какие действия после показа пользователю?

ATT>"типа пусть падает, нам же проще будет отловить" звучит как-то детски, уж извините.
Если НУЛЛ появился там, где по логике его не должно быть — значит где-то ошибка. Не лучше ли, чтоб всё завалилось поближе к месту её возникновения, вместо того, чтоб программа начала вести себя неправильно (ошибка же) и приводила к непредсказуемым или ошибочным результатам?

Здравствуйте, 24, Вы писали:

24>Здравствуйте, AnonThisTime, Вы писали:

ATT>>и в случае ошибки валят исключение, которое ловится глобальным уловителем (и показывается юзверю) либо вызывающим методом;
24>А какие действия после показа пользователю?

Если это ожидаемое исключение, его должен ловить вызывающий метод и возвращать программу к рабочему состоянию (например, снимать оповещение "Подождите, идет выполнение" и переходить в состояние "жду команды" и т.п.).
Если это неожидаемая ситуация, то тут зависит от назначения/надежности и т.п. ПО: 1) показать окно с исключительной ситуаций и забить, в надежде, что пользователь/ваша система сообщим об ошибке. При этом ПО будет в нестабильном состоянии (контролы остались заблокированы и т.п.) 2) ждать от таких методов возникновения неожидаемых исключений и действовать как в случае ожидаемых — приводить состояние системы в порядок. Каждый разраб идет своим путем тут. Я лично иду вторым.

ATT>>"типа пусть падает, нам же проще будет отловить" звучит как-то детски, уж извините.
24>Если НУЛЛ появился там, где по логике его не должно быть — значит где-то ошибка. Не лучше ли, чтоб всё завалилось поближе к месту её возникновения, вместо того, чтоб программа начала вести себя неправильно (ошибка же) и приводила к непредсказуемым или ошибочным результатам?

никто и не говорит, что при завале первого метода, нужно пытаться вызвать второй, авось что-то и выйдет. Все, ошибка уже случилась, дальше пути нет. Вопрос был проверять ли такие ситуации или "пусть будет, как будет".
В моем ответе речь шла о том, что нужно всегда контролировать ситуацию и приводить ПО в стабильное состояние после таких ошибок, чтобы можно было работать дальше, если это была не смертельная ошибка. Иначе юзверь после каждого исключения будет перезапускать ПО => нервов его хватить на час, далее uninstall.

Здравствуйте, AnonThisTime, Вы писали:

ATT>зависит от ситуации, но я бы советовал проверять всегда, если это не поделка на коленке. Использую простую логику: public/internal/protected методы — все параметры валидируются всегда и в случае ошибки валят исключение, которое ловится глобальным уловителем (и показывается юзверю) либо вызывающим методом; private методы — параметры не валидируются никогда.

Если речь о проверке на null, то какая принципиальная разница завалится ли код на проверке аргумента или парой строчек кода ниже — на обращении к аргументу?

Я бы сказал, что смысл в проверках на null имеется в том случае, если null это валидное значение, соответственно код такой аргумент должен корректно обработать и продолжить работу. А если null это невалидное значение, которое непонятно как в данном месте можно обработать, то разницы упадет код на проверке или на обращении практически никакой.