kolesov,

Если интерфейс через web, то там вроде как параметр есть, в котором указывается страница для ошибок, написанная вами, где вы можете обработать различные случаи.
А так, ошибки то разные бывают. Мне кажется не нужно прятать от пользователей таких ошибок, вы "отнимаете" у них возможность отправить её Вам по почте в случаях, когда у вас не получается воспроизвести ошибку.

А вообще, конечно, зависит от того, через какой интерфейся пользователь взаимодействует с системой, я так думаю.

Блок А.Н.В программах ставим обработчики ошибок, которые обеспечат корректный выход влюбом случае,
$ET или $ZT.

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

А вообще мне гораздо больше нравится больше информации об ошибке(красно-синее окно на весь экран), так как сокрытая ошибка типа "я вот так делаю, а оно ничего не делает" даже меня может поставить в тупик, не сразу сообразишь, что нужно посмотреть в журнале ошибок.

Сейчас IS вроде бы советуют переходить на try{...} catch (err) {...}.

krvsaneznauСейчас IS вроде бы советуют переходить на try{...} catch (err) {...}.
Смысл переходить на что-то другое если есть уже работающее и удовлетворяющее потребностям?

На данный момент главный аргумент - читабельность кода увеличивается.

А так, вдруг IS снимет с поддержки $ze и $zt. Надо заранее готовится :)