<div dir="ltr">I personally think the standard is poorly defined here.  It allows for the case that get_unexpected can return null.  It also allows it to be legal to call set_unexpected with null, but doesn't specify whether that means set the default handler.  <div><br></div><div>libc++ allows null but unexpected() will crash if called in when the unexpected handler is null.  Also it doesn't have any code to set the default handler out of the box (unless I'm missing something).  Any idea why this is the case?  The reason I brought this up is that tests were asserting and crashing for me (with MSVC) because in my build I haven't (yet) done anything to set a default.</div><div><br></div><div>I personally think the robust solution for behaviour is to return null from the outset and have std::unexpected just call terminate if the current handler is null.  That way there's no nasty behaviour.  However, if the choice for libc++ is to have a non-null handler then is there any reason not to add code to set that automatically (to std::terminate) and possibly add code to do something sane when null is passed in?</div><div><br></div><div>Anyway, I won't stress too much about this as it's deprecated in c++11 and not going to end my world.  Just curious as to why things are the way they are.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 7:55 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Jul 15, 2015 at 11:56 PM, Andrew Parker<br>
<<a href="mailto:andrew.j.c.parker@gmail.com">andrew.j.c.parker@gmail.com</a>> wrote:<br>
> The test:<br>
><br>
> \test\std\depr\exception.unexpected\set.unexpected\get_unexpected.pass.cpp<br>
><br>
> expects the initial unexpected handler to be non-NULL:<br>
><br>
> int main()<br>
> {<br>
><br>
>     std::unexpected_handler old = std::get_unexpected();<br>
>     // verify there is a previous unexpected handler<br>
>     assert(old);<br>
><br>
> Is that really a requirement?<br>
<br>
</div></div>I believe so, yes. [unexpected.handler]p3 says: "The implementation’s<br>
default unexpected_handler calls std::terminate()." which suggests<br>
that there be an initial default unexpected_handler that is nonnull.<br>
<br>
~Aaron<br>
<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
</blockquote></div><br></div>