1. Изменять до неузнаваемости незачем — есть хорошая техника цепных исключений.
2. Можно логировать выброшенное исключение сразу — до начала раскрутки стека.
Видел я такие проги — легче от этого не было никому. Куча защитного кода, увидеть за которым логику программы не может даже автор через пару месяцев.
Кстати, WinAPI тоже может бросать исключения.
А писать на голом Win32 — это для мазохистов
За бизнес-логику на исключениях — жестоко караю на ревью.
Так теряются все плюсы исключений:
1. Код чистой бизнес-логики перестает хорошо читаться.
2. Производительность идет лесом.
3. Лог засоряется исключениями, которые не являются сбоями.
1. Вот такой синтаксис для Delphi означает присваивание полю или свойству объекта:
self.p := P.Create;
2. Вы говорите, простите, ересь. Того, кто освобождает ресурсы вне блоков finally или деструкторов (деструктор в Delphi — аналог finally для объектов) — больно и обидно бьют. За утечки при выбросе исключений.
Я читал про проблемы плюсовых исключений, но так как сам на них не пишу — не имею своего мнения :) В Delphi исключения вкусны и полезны при правильном их использовании — обозначении явных редких сбоев.
Не встречал на Delphi непонятно падающего кода: даже в самых сложных случаях успешно отлавливал косяки в сторонних библиотеках, которые при использовании кодов ошибок хрен бы нашел.
С точностью до наоборот — подключая чужую библиотеку, я жду от нее, что она или вернет мне валидные данные или явно обозначит сбой выбросом исключения. Иначе я не смогу доверять библиотеке и буду вынужден писать тонны защитного кода с проверками, затрудняющими понимание моих собственных алгоритмов.
Последний абзац — серьезное заблуждение. Внешний мир для любой программной единицы несовершенен.
Функцию МОЖНО вызывать с невалидными значениями аргументов.
Файл МОЖЕТ оказать заблокирован другим процессом.
Сервер БД МОЖЕТ оказаться недоступным.
Это все — сбои вне вашего кода, сообщить о которых в большинстве языков можно двумя способами — кодом ошибок или исключениями. Второе много лучше по следующим причинам:
1. Исключение автоматически всплывает по стеку и больно бьет — код ошибок без сознательных усилий глотается
2. Исключения в ООП-языках можно наследовать — коды ошибок только добавлять новые.
3. «Бархатный путь» (основной алгоритм без сбоев) при использовании исключений читается гораздо лучше
Код в A.Foo — плохой. Очень.
1. Если один и тот же ресурс выделяется и освобождается в пределах одного метода, то его не следует делать полем объекта.
2. Освобождение поля объекта следует делать в деструкторе, а локальной переменной — в блоке finally.
try..except при нормальной работе нужен всего в трех случаях:
1. Предотвращение утечек в фабричных методах.
2. Повторный выброс исключения на границах абстракции (превращение «Не могу открыть файл» в «Не могу записать в лог»).
3. Собственно разбор полетов, там где нужно восстановление, повтор, логирование и т.п.
Это не есть правильно, потому что в нормальных VCS версию имеет не файл, а репозитарий, что абсолютно логично для исходных тесктов программ, автоматически обеспечивая их согласованность между собой.
Т.е. вместо того, чтобы спокойно сделать update рабочей копии и получить новую версию или не делать update, взяв merge на себя, мне автоматически ломают рабочую копию, обновить которую до согласованного состояния я должен уже руками?
2. Можно логировать выброшенное исключение сразу — до начала раскрутки стека.
Кстати, WinAPI тоже может бросать исключения.
А писать на голом Win32 — это для мазохистов
Так теряются все плюсы исключений:
1. Код чистой бизнес-логики перестает хорошо читаться.
2. Производительность идет лесом.
3. Лог засоряется исключениями, которые не являются сбоями.
2. Вы говорите, простите, ересь. Того, кто освобождает ресурсы вне блоков finally или деструкторов (деструктор в Delphi — аналог finally для объектов) — больно и обидно бьют. За утечки при выбросе исключений.
Функцию МОЖНО вызывать с невалидными значениями аргументов.
Файл МОЖЕТ оказать заблокирован другим процессом.
Сервер БД МОЖЕТ оказаться недоступным.
Это все — сбои вне вашего кода, сообщить о которых в большинстве языков можно двумя способами — кодом ошибок или исключениями. Второе много лучше по следующим причинам:
1. Исключение автоматически всплывает по стеку и больно бьет — код ошибок без сознательных усилий глотается
2. Исключения в ООП-языках можно наследовать — коды ошибок только добавлять новые.
3. «Бархатный путь» (основной алгоритм без сбоев) при использовании исключений читается гораздо лучше
1. Если один и тот же ресурс выделяется и освобождается в пределах одного метода, то его не следует делать полем объекта.
2. Освобождение поля объекта следует делать в деструкторе, а локальной переменной — в блоке finally.
try..except при нормальной работе нужен всего в трех случаях:
1. Предотвращение утечек в фабричных методах.
2. Повторный выброс исключения на границах абстракции (превращение «Не могу открыть файл» в «Не могу записать в лог»).
3. Собственно разбор полетов, там где нужно восстановление, повтор, логирование и т.п.
В остальных местах вполне хватает try..finally
Т.е. вместо того, чтобы спокойно сделать update рабочей копии и получить новую версию или не делать update, взяв merge на себя, мне автоматически ломают рабочую копию, обновить которую до согласованного состояния я должен уже руками?
Итак — есть интеграция с UML. Что еще?