Когда использовать throw?

[Inet_PC]

try|catch медленней чем if.

Вы правы только отчасти, вот в этой теме Psycho Tiger доказал мне, что выгодней использовать try/catch нежели if, ибо быстрее, и if выигрывает только когда ошибка. А ошибка это исключительная ситуации, в готовом приложении их количество должно быть гораздо меньше, чем нормальных.
1. try/catch приходится использовать при использовании нативных методов, к. генерируют исключения.
2. При вызове методов из других библиотек, ибо их автор возможно что-то не учел, или сам генерирует исключения и тут без try/catch так же не обойтись.
В общем случае я тоже за то, чтобы обходится if-ами.

[GBee]

Вы правы только отчасти, вот в этой теме Psycho Tiger доказал мне, что выгодней использовать try/catch нежели if, ибо быстрее, и if выигрывает только когда ошибка. А ошибка это исключительная ситуации, в готовом приложении их количество должно быть гораздо меньше, чем нормальных.

Если честно не очень понял, там по теме в if дергался неслабенький метод с блекджеком и циклами. Впрочем в с Тигрой там к этому и пришли, как я понял.

В общем случае я тоже за то, чтобы обходится if-ами.

+1 и правильная архитектура, а не как в той теме :о)

[Psycho Tiger]

Вот при обращении к свойству, которое null генерируется RTE (я про value.key, когда value = null).
Вы представляете, если бы генерировалось событие, например? Вот в таких вещах оно и надо. В ядре. RTE не должны выбрасываться в продакшн-версии, зато если оно вывалилось при девелопе - можно сразу понять, что было сделано не так. Как уже подметили, IDE сваливается в дебаг.

[expl]

Про то зачем нужны ислючения и когда ими надо пользоваться очень хорошо написано в древней, христоматийной крижке Стива Макконнела "Совершенный код"
http://www.ozon.ru/context/detail/id/3159814/
Там именно про стратегии использования (включаяя assert'ы) - про обработку ошибок в месте их появления, не допуская их в глубь программы, где уже не разберешься кто виноват.
Про эшелоны борьбы с ошибками.

Основные принципы по киданию исключений:
- Если метод сам не в состоянии правильно отреагировать на кривые данные - ну не знает он о другой части системы - вот с помощью исключения он и передает обработку ошибки выше
- Если метод более высокого уровня тоже не может ничего сделать (например показать окошко "Попробуйте еще" или откатить правки, или перезагрузить данные, или тупо в лог вывести, или вообще показать окно "В конфиге неправильный адрес - правьте и перезагружайтесь")
то он должен передавать более высокому в иерархии методу более детальное исключение, не просто "null-exception", а описание чего пытались сделать и почему не получилось - более высокий метод же не должен в низком уровне иерархии для этого копаться.
И т.д. и т.п.

Если запись не добавилась, то в что лучше делать на стороне клиента - выбрасывать исключение или просто прекращать работу метода (return) и выводить сообщение юзеру об ошибке(Alert.Show)?

Конечный пользователь в идеале не должен видеть исключения _никогда_. Исключение кидают не чтобы появилось забавное окошко со стеком вызвовов, а чтобы подсистема более высокого уровня отреагировала на ситуацию.
Можно, конечно и без исключений, но тогда из функции придется как-то получать информацию об ошибке, т.е. код усложниться просто.

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

Пользователь должен видеть, то, что ему понятно. На худой конец, чтобы принимать баг-репорты можно сделать флешовое окошко, в котором будет кнопка "Send to support", по которой вам на мыло придет этот самый стек вызовов.

[kackbip]

RTE не должны выбрасываться в продакшн-версии

Если они перехватываются - почему бы и нет.

[goodguy]

Не вижу смысла самому кидать ошибку, и самому же ее перехватывать )

[carrotoff]

Не вижу смысла самому кидать ошибку, и самому же ее перехватывать )

Смысл будет заметнее, если занимаешься разработкой не один. Но если всё-таки один, то в принципе согласен

[kackbip]

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

Не вижу смысла самому кидать ошибку, и самому же ее перехватывать )

Угу... а так же нет смысла генерировать события и самому их обрабатывать?

[carrotoff]

Угу... а так же нет смысла генерировать события и самому их обрабатывать?

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

[kackbip]

Не, ну это утрирование

Я соглашусь если ты мне покажешь принципиальную разницу между исключением и событием ошибки.