Про то зачем нужны ислючения и когда ими надо пользоваться очень хорошо написано в древней, христоматийной крижке Стива Макконнела "Совершенный код"
http://www.ozon.ru/context/detail/id/3159814/
Там именно про стратегии использования (включаяя assert'ы) - про обработку ошибок в месте их появления, не допуская их в глубь программы, где уже не разберешься кто виноват.
Про эшелоны борьбы с ошибками.
Основные принципы по киданию исключений:
- Если метод сам не в состоянии правильно отреагировать на кривые данные - ну не знает он о другой части системы - вот с помощью исключения он и передает обработку ошибки выше
- Если метод более высокого уровня тоже не может ничего сделать (например показать окошко "Попробуйте еще" или откатить правки, или перезагрузить данные, или тупо в лог вывести, или вообще показать окно "В конфиге неправильный адрес - правьте и перезагружайтесь")
то он должен передавать более высокому в иерархии методу более детальное исключение, не просто "null-exception", а описание чего пытались сделать и почему не получилось - более высокий метод же не должен в низком уровне иерархии для этого копаться.
И т.д. и т.п.
Цитата:
|
Если запись не добавилась, то в что лучше делать на стороне клиента - выбрасывать исключение или просто прекращать работу метода (return) и выводить сообщение юзеру об ошибке(Alert.Show)?
|
Конечный пользователь в идеале не должен видеть исключения _никогда_. Исключение кидают не чтобы появилось забавное окошко со стеком вызвовов, а чтобы подсистема более высокого уровня отреагировала на ситуацию.
Можно, конечно и без исключений, но тогда из функции придется как-то получать информацию об ошибке, т.е. код усложниться просто.
Зачем это окошко пользователю? Тем более если флешплеер не дебажный - он вообще об ошибке не узнает.
Пользователь должен видеть, то, что ему понятно. На худой конец, чтобы принимать баг-репорты можно сделать флешовое окошко, в котором будет кнопка "Send to support", по которой вам на мыло придет этот самый стек вызовов.