This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: list::_M_check_equal_allocators throws


On 18 September 2013 20:26, François Dumont wrote:
> On 09/17/2013 05:52 PM, Jonathan Wakely wrote:
>>
>> I support adding noexcept specifications to places that shouldn't throw,
>> even if that prevents us using exceptions to identify undefined behaviour,
>> like this case. Others might disagree though, and prefer having an exception
>> thrown, so I'm interested to hear what other people think.
>
>     In one of my TODOs for debug mode was the possibility for users to
> request exceptions instead of an abortion on debug checks. In plugin
> oriented application we have nowadays it is quite painful to have one of the
> plugin to collapse the whole application because of some internal issue
> while it could be simply unloaded. I know that we can't always provide
> strong exception safety guaranty but I still think it worth the effort.
>
>     But that would be for debug that might not have the same noecept
> specification as the normal mode.
>
>     Maybe this choice between abortion or exception could be a user decision
> through a configuration option. And not necessarily limited to the debug
> mode.

Thanks for sharing your thoughts.  I'm not sure I like this idea of
debug mode as a safety net for buggy software though :-)

In my view the point of debug mode is to help find bugs during a
development phase, not to aid in error recovery in production
software.  If you are developing a plugin and it contains bugs then
surely you want to know exactly where and when the bug happened (which
a core file tells you) rather than just unload it and say "something
went wrong, the plugin was closed." If you not developing the plugin
and are simply the user of a plugin then I don't think it should have
been built with debug mode anyway.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]