Открыл для себя гарантии безопасности исключений и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены. Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы? Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
Здравствуйте, Termit, Вы писали:
T>Открыл для себя гарантии безопасности исключений и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены. Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы? Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
У вас какие-то слишком сложные представления об исключениях. Исключения это всего лишь механизм передачи управления, упрощающий выход их методов в случае ошибочных и близких к ним ситуаций.
Здравствуйте, Blazkowicz, Вы писали:
B>У вас какие-то слишком сложные представления об исключениях. Исключения это всего лишь механизм передачи управления, упрощающий выход их методов в случае ошибочных и близких к ним ситуаций.
Не сложные, скорее правильные
Тут еще дело затруднено языком — если это С++, то еще надо узнать какая библиотека используется. В теории, можно попробовать поставить try..catch в методе, вызывающем обработчики событий.
Здравствуйте, Termit, Вы писали:
T>Открыл для себя гарантии безопасности исключений и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены. Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы? Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
А поделитесь-ка с нами источником почерпнутой вами мудрости, ссылку в студию! А то складывается ощущение, что то ли вас обманули жестоко, то ли вы как-то превратно поняли материал.
Как минимум, что уже видно:
перехватывать все исключения бессмысленно и чревато;
перехватывать исключение и после этого хоть бы хны, спокойно продолжать выполнение программы — как наступив на граблю, отойти и снова наступить на нее или другую граблю, что уже побольше в размерах.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Blazkowicz, Вы писали:
B>>У вас какие-то слишком сложные представления об исключениях. Исключения это всего лишь механизм передачи управления, упрощающий выход их методов в случае ошибочных и близких к ним ситуаций. C>Не сложные, скорее правильные
C>Тут еще дело затруднено языком — если это С++, то еще надо узнать какая библиотека используется. В теории, можно попробовать поставить try..catch в методе, вызывающем обработчики событий.
Язык С++, библиотека WTL. Т.е вы предлагаете поставить try/catch в главной функции-обработчике сообщений?
Здравствуйте, rsn81, Вы писали:
R>А поделитесь-ка с нами источником почерпнутой вами мудрости, ссылку в студию! А то складывается ощущение, что то ли вас обманули жестоко, то ли вы как-то превратно поняли материал.
R>Как минимум, что уже видно:
перехватывать все исключения бессмысленно и чревато;
R>перехватывать исключение и после этого хоть бы хны, спокойно продолжать выполнение программы — как наступив на граблю, отойти и снова наступить на нее или другую граблю, что уже побольше в размерах.
Источник — Новые сложные задачи на C++, Автор: Герб Саттер
т.е надо разумно перехватывать исключения на уровне бизнес-логики, а если что то пролезло в UI то это уже ошибка, которая должна быть устранена во время отладки?
Здравствуйте, Termit, Вы писали:
C>>Тут еще дело затруднено языком — если это С++, то еще надо узнать какая библиотека используется. В теории, можно попробовать поставить try..catch в методе, вызывающем обработчики событий. T> Язык С++, библиотека WTL. Т.е вы предлагаете поставить try/catch в главной функции-обработчике сообщений?
Да, сильно лучше не получится.
И при перехвате исключения показывать диалог, предлагающий послать автору сообщение об ошибке (я для этого использовал CrashRpt: http://code.google.com/p/crashrpt/ ). По идее, самым разумным действием после перехвата будет выключить программу, постаравшись сохранить данные. Но можно и попробовать продолжить — это возможно сделать.
Здравствуйте, rsn81, Вы писали:
R>А поделитесь-ка с нами источником почерпнутой вами мудрости, ссылку в студию! А то складывается ощущение, что то ли вас обманули жестоко, то ли вы как-то превратно поняли материал.
Это из С++, есть такая фича — гарантии по исключениям. Их там четыре штуки: no throw (метод никогда не бросит исключение), weak (метод может бросить исключение, после исключения объект безопасно может быть только уничтожен), strong (метод может бросить исключение, при броске происходит откат изменений, объект можно использовать дальше), none (никаких гарантий).
Видимо, человеку захотелось сделать своему коду хоть какие-то гарантии
Уже недавно кому-то говорил, повторюсь:
Возможно Вам будет интересно (если Вы еще этого не сделали) почитать МакКоннелла — Совершенный Код, кажется в главе 8 про обработку ошибок, начинающему/среднеуровневому разработчику может быть полезно.
Здравствуйте, Termit, Вы писали:
T>Источник — Новые сложные задачи на C++, Автор: Герб Саттер
Тогда пас: раз Cyberax говорит, что в C++ такой изврат обоснован.
T>т.е надо разумно перехватывать исключения на уровне бизнес-логики, а если что то пролезло в UI то это уже ошибка, которая должна быть устранена во время отладки?
По-крайней мере в управляемых платформах практически все исключения (кроме специальных) — это не ошибка, а информационное сообщение, на которое надо соответствующим образом реагировать. Уже писали тут: Re: Гарантии безопасности исключений в GUI
> R>А поделитесь-ка с нами источником почерпнутой вами мудрости, ссылку в студию! А то складывается ощущение, что то ли вас обманули жестоко, то ли вы как-то превратно поняли материал. > > R>Как минимум, что уже видно:
перехватывать все исключения бессмысленно и чревато;
> R>перехватывать исключение и после этого хоть бы хны, спокойно продолжать выполнение программы — как наступив на граблю, отойти и снова наступить на нее или другую граблю, что уже побольше в размерах.> > Источник — Новые сложные задачи на C++, Автор: Герб Саттер > т.е надо разумно перехватывать исключения на уровне бизнес-логики, а если что то пролезло в UI то это уже ошибка, которая должна быть устранена во время отладки?
Не обязательно, все сильно зависит от контекста. Если на уровне бизнес-логики можешь дописать к исключение что-нибудь умное, например, поймав my_security_wrapper::access_deined, вместо просто e.what() выдать в качестве сообщения об ошибке string("Открытие файла xxx обломилось по причине: ") + e.what(), то лучше так и сделать. А если и без этого юзеру будет понятно, в чем проблема, то пускай себе летит на самый верх. Кроме того, понятное дело, что в ряде случаев возникновение исключения означает, что дальнейшие операции с данным объектом будут приводить либо к дальнейшим исключениям, либо вообще к AV — в таких случаях, естественно, перехват исключения на уровне БЛ обязателен, поскольку необходимо уничтожить сам объект, отвечающий за взаимодействие с ним GUI, а сообщение об ошибке показать позднее.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
C>Это из С++, есть такая фича — гарантии по исключениям. Их там четыре штуки: no throw (метод никогда не бросит исключение), weak (метод может бросить исключение, после исключения объект безопасно может быть только уничтожен), strong (метод может бросить исключение, при броске происходит откат изменений, объект можно использовать дальше), none (никаких гарантий).
Здравствуйте, Sergey Chadov, Вы писали:
C>>Это из С++, есть такая фича — гарантии по исключениям. Их там четыре штуки: no throw (метод никогда не бросит исключение), weak (метод может бросить исключение, после исключения объект безопасно может быть только уничтожен), strong (метод может бросить исключение, при броске происходит откат изменений, объект можно использовать дальше), none (никаких гарантий). SC>А причем здесь С++?
В общем и целом — ни при чем. Но во многих управляемых средах (в JVM и CLI — точно), декларировано, что в любой момент может вылететь исключение ("ошибка VM", например). Так что часть гарантий уже, строго говоря, сделать не получится.
Здравствуйте, Termit, Вы писали:
T>Открыл для себя гарантии безопасности исключений и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены.
Перечитал "Вопросы и приёмы безопастности исключений" из указанного
источника. На основании чего был сделан вывод о том, что "все исключения должны быть перехвачены"? Должны быть перехвачены исключения, которые описаны в контракте (явном или не явном) вызываемых методов.
T>Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы?
Если UI работает через очередь сообщений, то обработчик исключения можно выставить над обработчиком сообщения, перехватив, таким образом, ошибки во всех обработчиках всех (или только нужных) сообщений. Насколько просто и удобно это сделать зависит от используемой GUI-библиотеки. Про WTL не знаю.
T>Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
Такой "глобальный" обработчик, как сказано выше, позволит "продолжить выполнение".
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Termit, Вы писали:
T>Открыл для себя гарантии безопасности исключений и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены. Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы? Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
Если для WTL то примерно так:
class CHTMLView :
public CWindowImpl<CHTMLView, CHTMLayoutCtrl>,
public CHTMLayoutHost<CHTMLView>
{
BEGIN_MSG_MAP(CHTMLView)
try
{
MESSAGE_HANDLER(WM_CREATE, OnCreate)
MESSAGE_HANDLER(WM_MOUSEMOVE, OnMouseMove)
MESSAGE_HANDLER(WM_RBUTTONUP, OnMouseUp)
}
catch(logic::error& e)
{
...
}
END_MSG_MAP()
...
Но как-то это концептуально неправильно. Реально
все методы кроме WM_COMMAND не должны бросать исключения.
WM_COMMAND — это то место где управление уходит в логику и по всей видимости
там должно и обрабатываться.
Например ошибка открытия файла должна обрабатываться по месту.
Скажем в BlockNote при ошибке открытия файла загружается default (empty) document.
Обрабатывать сие в общем event handler — как-то неправильно.
и захотел их использовать в GUI приложении. Насколько я понял концепцию, надо, как минимум, гарантировать что все исключения должны быть перехвачены. Из UI вызывается 90% кода, соот-но надо наставить во всех UI callback-ах try/catch? Есть еще какие нибудь подходы? Глобальный обработчик не подходит потому что хочется продолжить выполнение программы.
