Когда использовать throw? - Страница 3

goodguy · 14.11.2011, 12:10

Цитата:

событием ошибки

ну сначала то ты сказал просто про событие как таковое

GBee · 14.11.2011, 12:40

Цитата:

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

Ошибку может кинуть любой ду объект, а событие только IEventDispatcher. Насчет "всплытия" ошибки из глубин вложения не знаю. A "ранний" try|catch останавливает ошибку или она дальше будет ловиться во внешнем?

expl · 14.11.2011, 12:48

Цитата:

Сообщение от goodguy

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

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

Если не бросать исключение, придется делать каке-то поля, в которые метод будет записывать что он сработал не верно и что именно было не верно

alatar · 14.11.2011, 13:03

Простой пример, запретить вызов метода. Контейнеры spark используют методы addElement / removeElement и не умеют работать с методами addChild / removeChild, но т.к. в основе они DisplayObjectContainer, то эти методы в них присутствуют. Вот для запрета их использования и кидается ошибка. И событие тут не прокатит.

crazyone · 14.11.2011, 13:41

Например, когда разрабатываются библиотечные методы - очень полезно не просто проверить валидность аргументов, но и бросить объясняющий ошибку ArgumentError, чтобы пользователь библиотеки знал, где он ошибся и что не так сделал. С молчаливыми библиотеками сложнее работать.
И вообще - читайте книжки. В самом базовом примере про деление на ноль объясняется преимущество исключений перед if/else.

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