Andrey Semashev wrote: On Monday, June 15, 2009 5:24 PM
On Monday 15 June 2009 19:42:18 Stewart, Robert wrote:
2. An exception is not a good choice to highlight the problem, since in most cases it will be swallowed by IO streams. In practice streaming errors (in form of failbit or badbit) are often ignored, and Boost.DateTime is an example. And ios_base::failure usually isn't as descriptive as what is being initially thrown.
Sorry, but no. The default is for IOStreams to set the stream state to indicate failures, but that doesn't absorb exceptions from code such as we're discussing and convert exceptions into stream state.
It does adsorb exceptions, at least on my GCC 4.3.2. But it does pass through original exceptions if exceptions are enabled, but I'm not sure it's guaranteed by the standard. You can play with the attached code sample to test your platform.
I went back and reread 27.6.1.2.1. Despite my confident assertion above, there is no distinction made as to the source of exceptions caught. It says, "if an exception is thrown during input then ios::badbit is turned on in *this's error state." I'm sorry for the noise. Throwing an exception, however, does mean that it will propagate from a stream when configured to permit that. Setting badbit is the best that can be done otherwise and seems necessary, even if it is ignored, as it will prevent further operations on the current stream until cleared. That may draw attention to the code using that stream as the result will deviate from the expected. Obviously, badbit can be set without throwing an exception, but the chance for the exception to propagate, with the side effect of setting badbit, means throwing one is worthwhile.
3. The caller has to check the arguments. It's the bottom line of both STL and most C functions. Extensive error checking may be provided but it should be optional. An assert fits perfectly.
A well designed library prevents misuse.
Right. But since DateTime IO is based on facets, there isn't much room for design decisions. As for the exception, it does not prevent misuse. It *may* show when the feature *have been* misused.
Since there's little room for design decisions, why not avail ourselves of all options at our disposal? If throwing an exception doesn't reveal the misuse because exceptions are absorbed, badbit is ignored, and the incorrect result isn't noticed, then there's nothing to be done. However, exceptions may be enabled, badbit may be noticed, and the incorrect result may be noticed, so throwing an exception increases the chance of detecting the misuse.
We can debate on this. There are people that prefer safety at all costs. There are other people, including me, that don't want to pay for unnecessary run time checks. My position is that there are no guarantees if the code is used incorrectly. If I want safety, I do the proper testing, including debug builds and invalid input to my system to verify that it tackles it well. One advantage of the assert is that it can satisfy both safety and performance needs.
We're discussing testing the input against a limit in the midst of all of the normal IOStreams overhead, including multiple virtual function calls. This hardly amounts to performance robbing overhead. An assertion does not satisfy safety concerns completely, and the test to decide whether to throw an exception is no performance drag. Obviously, if the exception is actually thrown, there is real performance effect, but those with your concern for testing well and best performance will have already detected and prevented the condition leading to the exception. The question is whether to change the default formatting for time durations. If done, the question of an exception versus or in addition to an assertion is moot. If not done, for compatibility reasons, then throwing an exception following the assertion is the ideal, best effort way to report the misuse. There's also the issue of whether %O was the right format specifier in the first place, and Jeff Garland must answer that question. (He could opt to accept %OH as a special case equivalent to %O, leaving the latter for compatibility with existing code and documenting the former as the proper means to get the desired formatting. He could even choose to deprecate %O in favor of %OH and remove it some time in the future.) We've beaten on this subject long enough. Jeff must chime in and make the calls. I BCC'd him to try to draw his attention to the discussion. Now we wait. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; 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.