Exception, например при работе с БД, не очень помогает, т.к. не полность есть реализация. Было время я его наверно весь перерыл (класс). Это я к тому, что без on E: Exception do можно иногда и обойтись. А иногда просто выбора нет тоon E: Exception do автоматически не расматривается.
Не совсем понял мысль, но как-нибудь отвечу. Если мне надо было отслеживать именно ошибки при работе с БД то я писал так:
try
{some DB operations}
except
on E: EIBError do sErrMsg:=E.Message;
end;
Как видно, здесь просто выщемляются эксцепшены от IBX, а на остальные плевать. Имеет смысл иногда отлавливать ошибки конкретного типа, чтобы внятно известить юзера, чего случилось, или записать в лог.
я не перемешал мухи и котлеты. Вопрос не стоит об обработке исключений. человеку нужно пропуститьь ошибку, если она возникла. Чем конструкция плохая? А те знакома ситуация когда вылетела ошибка в проекте, а в исключении написано "No error"?
Если ему плевать, что там за ошибка, то его может устроить и блок
try...finally, а если уж смотреть, что за исключение, то функции GetLastError() SetLastError() мало чем помогут, поскольку они относятся к Win32 API и нифига толкового не покажут, если исключение возникло в компоненте по причинам не зависящим от операционки (типа "index out if bounds" или "not valid какое-то value"). Т.е. я имел ввиду, что использование этих функций может иметь смысл только при отлове ошибок во время работы с Win API.
: Вниз