try вообще лучше не использовать там, где можно обойтись без него.

Без исключений можно обойтись всегда, значит не использовать из совсем ;)? Коды возврата, C-style?

Ну и скриншот из второго поста, как бы говорит что это не тот случай, когда можно обойтись :). Хотя я до сегодняшнего дня даже и не знал, что flash.media::Sound/play может выбросить исключение.

а я иногда использую исключение, когда надо быстро выйти из n-вложенной ф-ии (не в смысле, что она определена в другой, а та в третьей и т.д., а в том, что одна вызывает другую, та третью и т.д.) и на нужном уровне перехватываю исключение.

Увлекательно. Только людей жалко. Надо бы всяких одиозных личностей подвесить.:D

Гитлеров? :D

Try нужно использовать, но к месту. Например, насколько я помню, была такая ситуация, что нужно сохранение > 100КБ в шаредОбжект сделать.

Выяснить, установил ли пользователь размер шареда в настройках флеша на >100Kb можно было только через трай\кетч, при этом в трае был so.flush(), а в кетче вызывалось окно System.showSettings(1);.. Как то так примерно

В остальных случаях try почти бесполезен, как правило

TERRORist сказал пример, когда использовать можно. Если есть вариант, где его не использовать - значит его не использовать. Даже в одной строчке кода может быть много RTE, обернув её в try мы уже потенциально не узнаем о возможной ошибке там. Это уже не говоря что try жутко медленный.

orcpochta, то что вы сказали называется стек. То что вы делаете - называется хрень, RTE созданы для ошибок, а не для штатных ситуаций. Если вы предполагаете, что у вас в штатной ситуации должно вызваться RTE - у вас явно проблемы с архитектурой. С вами и вашим кодом с такими подходами я бы работать не захотел.

Еще раз, flash.media::Sound/play может выбросить исключение, не могу представить как это получилось, но факт. Стало быть обернуть play в try/catch и есть то самое использование к месту. Я полагаю, что когда вы писали свой первый пост в этом топике, то просто не знали об этом, впрочем, я вот тоже не знал. Остальные play обернуты по причине того, что звуки в игре ассоциированы со строками, т.е. что-то в духе SoundManager.plya(sound_name), а собственно flash.media::Sound создается посредством getDefinition, который может выбросить исключение в случае ошибочного sound_name. Так что делать заключения о том хороший кодер или плохой кодер на основании минимальной информации на форуме делают вас не очень хорошим HR :). Последняя фраза шутка, если что.

Добавлено через 3 минуты
Использование throw вместо goto, порождает тот же самый спагетти код, что и goto :).

Добавлено через 12 минут
Исключения и созданы для более простой обработки ошибок, а не чтобы затруднить отладку.

Напишите простой тест производительности, откроете для себя много нового ;).

Это показывали ещё в презентациях старых о производительности. Тесты писать лень, для разницы надо сделать глубокий стек, т.к. при RTE он выгружается.

RTE созданы для облегчения отладки. try-catch для мест, в которых ошибки никак не избежать, или избегать её глупо. Если когда фп дал Вам ошибку, которую Вы не состоянии понять и Ваше решение было обернуть это в try-catch - это Ваше и только Ваше право. Только ни о каких гарантиях работоспособности этого кода идти речь не может.

Psycho Tiger, smrad, я не соглашусь с вами.

На живом примере: есть лабиринт, который надо обойти, событие "выход найден" возникает раз за несколько сот-тысяч "шагов" в зависимости от размера лабиринта, при этом надо обязательно вернуться на несколько уровней выше, чтобы продолжить стандартные схемы движения, но уже в направлении выхода. Если бы не возможность выбросить ошибку, мне бы пришлось в каждом надметоде определятьне вернул ли вложенный ниже метод нечто, сигнализирующее, что лабиринт найден. В итоге в зависимости от глубины вложенности мы имеем n дополнительных проверок, помноженных на несколько сот-тысяч шагов. Ну и зачем мне это надо?