Re: [boost] [chrono][system] Make possible to don't provide hybrid error handling.

Subject: Re: [boost] [chrono][system] Make possible to don't provide hybrid error handling.
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-10-11 13:52:17

Vicente Botet wrote:
> Beman Dawes wrote:
>
> > * Return a special time_point value when an error occurs. Do
> > this by having time_point provide
> > "static constexpr time_point error();"  in addition to min()
> > and max(). Add something like this to the docs:
> > "Since most programs will run in only in environments where
> > clocks never fail, most programmers can safely ignore the
> > possibility of this value being returned."
>
> I don't like the addition of not_a_time_point value as the
> result of the standard prototype, as it forces the user to
> check any call to now(). If we think that in some platforms
> clock::now could result in an error that the user can do
> something about, we should use either an error code or an
> exception, but not an invalid value. If the user couldn't do
> anything, as this is an internal error, the standard behavior
> is enough.

+1

Unless there's a way to assert that a given platform never returns the invalid value, so programmers using that platform can write code that ignores the possibility, then safe programming practice requires adding the checks.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com





________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.