Re: New C2220: warning treated as error (MSVC 2015 build failure)

On 06/30/2016 10:47 PM, Markus Mohrhard wrote:
> On Thu, Jun 30, 2016 at 7:46 PM, Luke Benes <lukebenes@hotmail.com
> <mailto:lukebenes@hotmail.com>> wrote:
>     Ever
>     since 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=62c047ffb397802c09df9070492e70725928cadf
>
>     Author: Markus Mohrhard <markus.mohrhard@googlemail.com
>     <mailto:markus.mohrhard@googlemail.com>>
>     Date:   Mon Jun 20 09:02:47 2016 +0200
>
>         switch to EHs on windows
>
>     I'm getting the following build error with MSVC 2015 (32-bit MSVC
>     2013 still works).
>
>     [build CXX] svl/source/undo/undo.cxx
>     c:\lode\dev\core\svl\source\undo\undo.cxx(390) : error C2220:
>     warning treated as error - no 'object' file generated
>     c:\lode\dev\core\svl\source\undo\undo.cxx(390) : warning C4702:
>     unreachable code
>     C:/lode/dev/core/solenv/gbuild/LinkTarget.mk:189: recipe for target
>     'C:/lode/dev/core/workdir/CxxObject/svl/source/undo/undo.o' failed
>     make[1]: ***
>     [C:/lode/dev/core/workdir/CxxObject/svl/source/undo/undo.o] Error 2
>     make[1]: *** Waiting for unfinished jobs....
>     Makefile:258: recipe for target 'build' failed
>     make: *** [build] Error 2
>
> Most likely you need to remove the try .. catch block. As currently
> nobody is really using MSVC 2015 we are not going to see these issues.
> So if you plan to compile with MSVC 2015 you must fix most of them
> yourself until we finally switch.

The relevant code in svl/source/undo/undo.cxx

>         // delete all actions
>         while ( !m_aUndoActionsCleanup.empty() )
>         {
>             SfxUndoAction* pAction = m_aUndoActionsCleanup.front();
>             m_aUndoActionsCleanup.pop_front();
>             try
>             {
>                 delete pAction;
>             }
>             catch( const Exception& )
>             {
>                 DBG_UNHANDLED_EXCEPTION();
>             }
>         }

is interesting.  Since C++11, the destructor of the (abstract base) 
class SfxUndoAction is implicitly noexcept(true), so the catch block 
clearly cannot be reached.

However, from this code alone it is unclear whether some class derived 
from SfxUndoAction actually wants to throw exceptions during destruction 
(so all the relevant class's destructors---which would include 
SfxUndoAction as well as any other bases or non-static data members of 
the derived class that actually want to throw exceptions---would need to 
be explicitly marked as noexcept(true); even though the act of throwing 
exceptions from a destructor is of course rather poor design), or 
whether this catch block has always been redundant (and should probably 
have been left out from the start).