В некоторых случаях ошибки ATL вызывает AtlThrow()
, который реализован как ATL::AtlThrowImpl()
, который, в свою очередь, выдает CAtlException
. Последнее не очень хорошо - CAtlException
даже не получено из std::exception
, а также мы используем нашу собственную иерархию исключений, и теперь нам придется поймать CAtlException
отдельно и здесь, где много лишнего кода и подвержено ошибкам.Как надежно заменить установленный библиотекой обработчик ошибок моим собственным?
Похоже, можно заменить ATL::AtlThrowImpl()
с моим собственным обработчиком - определить _ATL_CUSTOM_THROW
и определить AtlThrow()
быть пользовательский обработчик перед включением atlbase.h
- и ATL будет вызывать специальный обработчик.
Не так просто. Некоторые из ATL-кода не находятся в источниках - он компилируется как библиотека - либо статический, либо динамический. Мы используем статический - atls.lib
. И ... он скомпилирован таким образом, что он имеет ATL::ThrowImpl()
внутри и некоторый код, вызывающий его. Я использовал инструмент статического анализа - он ясно показывает, что есть пути, по которым вызывается старый обработчик по умолчанию.
Чтобы убедиться, что я даже пытался «переопределить» ATL::AtlThrowImpl()
в своем коде. Теперь компоновщик говорит, что он видит два объявления ATL::AtlThrowImpl()
, которые, я полагаю, подтверждают, что есть другая реализация, которую может вызывать какой-то код.
Как я могу справиться с этим? Как полностью заменить обработчик по умолчанию и убедиться, что обработчик по умолчанию никогда не вызывается?
Вы правы, но проблема заключается в том, что AtlThrowImpl() является встроенной функцией, и те обрабатываются специально - http://blogs.msdn.com/b/aszego/archive/2010/05/12/override -atlthrow-with-care.aspx, поэтому нижняя строка - это текущий дизайн ATL, требует перекомпиляции библиотеки для замены обработчика. – sharptooth
Переопределение встроенных методов таким образом, конечно, невозможно. Я не вижу решения для этого, кроме как изменить заголовки и перекомпилировать всю библиотеку ATL. – Patrick