Thread: Value initialization using an empty pair of parentheses

Yup. And you just made it non-standard.

Oh - so the standard mandates that operator 'new' has an exception specification? Ok, well I'll just undo that then.

EDIT:

I see, post #22.

Yup. And don't forget that exception specifications are part of the function interface. So, removing them actually doesn't redefine the standard global functions. It creates a new unrelated function.

Ok, thanks. And what about delete? Do you know if it requires an exception specification?

EDIT: Ah, found it. Yes, it does.

Originally Posted by Mario F.

I also yet to see a convincing argument for the removal of exception specifications. Other than the usual because it's evil. Riight.

Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
Unfortunately the web version of the book seems to be down, so I don't have a link.

Originally Posted by cpjust

Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
Unfortunately the web version of the book seems to be down, so I don't have a link.

I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

Sounds interesting. Is that a pretty good read, besides what you mentioned?

One of the most important books in best code practices, Sebastiani. It's a must-have in my opinion.

Originally Posted by Mario F.

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

No, not with VC++ at least:

Originally Posted by MSDN

The C++ Standard requires that unexpected is called when a function throws an exception that is not on its throw list. The current implementation does not support this.

set_unexpected (<exception>)

Originally Posted by Mario F.

I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

I think that in a mission critical application, exception specifications lead to undesired coupling between code units. A unit of code must be aware of all possible contexts in which it could be called and guarantee that no exception would be thrown that could propagate through a function with an exception specification that bars that exception. To me this seems to defeat the purpose of code modularity while providing no real design benefit.

The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.

Originally Posted by brewbuck

The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.

Should probably had had an addendum to my post. To better clarify the question.

It's perfectly plausible to want a program abort in some mission critical scenarios where an unhandled exception is met. One example that occurs to me is that of PTA databases. I'd be hard pressed to believe that it isn't acceptable to design a system that, having designed its own exception hierarchy, doesn't want to take advantage of exception specifications to immediately abort execution on unhandled exceptions in certain scenarios. A condition that may guarantee the safety or consistency of data in real-time. Or simply to use exception specifications to expose exception or error handling rules in some middle-tier library.

An unhandled exception is by definition a problem that usually can't be solved. The standard makes this definition evident by calling std::unexpected() which by default calls std::terminate(). This is a language feature. And one that I can find useful on certain scenarios. More importantly because it didn't forget to give me the means to alter this behavior.

...

The alternative is not to use it. And we are given that option too. So, where exactly is the need to remove it from the standard? (note I refuse to use the obvious argument of backwards compatibility. We can ignore that for the sake of argumentation. I'm hoping for a more involving discussion).

This is what a exception specification does:

Code:

//for something like void func() throw (X, Y);

void func() {

    try {
        //something
    }
    catch (X) { throw; }
    catch (Y) { throw; }
    catch (...)  { std::unexpected(); }
}

There's an advantage in having moved to the function interface information that may be relevant to its user, instead of having it hidden away in the function definition. The disadvantages on the other hand are well known and documented (and on this thread too). So to deny there is never going to exist a scenario where exception specifications may be a useful and elegant solution is pretty much the C++ Never Argument, that we know very well is only true in one situation: Never say never.

This is particularly important to me, because I've found useful scenarios for exception handling that go beyond the conventional and too often alluded approach. It's, for instance, quite acceptable to me to want to use the exception infrastruture and semantics for error handling, instead of (or in addition to) exception handling. As long as there's a clear separation between the too, as long as I'm aware of he implications, as long as any performance hits are well within acceptable ranges, and as well as I guarantee a clear interface, just why not? It's just another idiom. I don't expect to do it often, I don't even expect to do it at all. But the option is there and it is very visible. I'd be a fool not to take it if the opportunity arises, simply because I'm told I shouldn't do it.

In contrast, by removing it from the implementation as VC++ has done (although I suspect I can recover it through the eh.h header), I'm removed of a language feature. For better and for worst. Doesn't strike me wise at all.

EDIT: hmm, this probably should be split...

Well what I actually meant was exception specifications should be removed from all standard functions, so that it's:

Code:

void* operator new( std::size_t _Count );

instead of:

Code:

void* operator new( std::size_t _Count ) throw( bad_alloc );

If people want to add them to their own code, they can go right ahead (although I still see no reason why they'd want to).

If exception specifications worked like they do in Java, then they'd be worth using.

Originally Posted by cpjust

Well what I actually meant was exception specifications should be removed from all standard functions

Possibly. Although this time is for me to wonder what you could possible want to throw other than bad_alloc in a function of this nature

I's exactly one example where the usage of an exception specification carries with it 2 obvious advantages, and no disadvantage:

- It exposes its exception handling semantics to the user.
- It enforces those semantics.

The alternative, no exception specification, can certainly be achieved without prejudice to the throw(std::bad_alloc). It's my guess you want to do that because you expect to throw something else other than bad_alloc. So, it's acceptable to conclude you want to do something else other than just allocate room. Probably some bookkeeping? Well, you have this mechanism at your disposal by encapsulating the allocator function in your own class.

If exception specifications worked like they do in Java, then they'd be worth using.

Hmm... I suppose you mean the static checking.
This is what Sutter has to say, this time about Java exceptions:

Quoting it here too:

Essentially, exception specifications are a wonderful idea in basic principle, but no one really knows how to design them.
There are two major approaches, and both have serious problems. Java chose static enforcement (at compile time, as suggested above), and C++ chose dynamic enforcement. Interestingly, I see Java people ask "why not enforce these dynamically?" about as often as I see C++ people ask "why not enforce these statically?"
Briefly:
When you go down the Java path, people love exception specifications until they find themselves all too often encouraged, or even forced, to add throws Exception, which immediately renders the exception specification entirely meaningless. (Example: Imagine writing a Java generic that manipulates an arbitrary type T…)
When you go down the C++ path, people love exception specifications until they discover that violating one means invoking terminate, which is almost never what you want.

Even more interesting is this article were checked and unchecked exceptions are discussed in great detail. Here too there's a clear case against static checking.

EDIT: Quite curious. Because I copy-pasted a quote from Sutter's blog, a script on his page added this thread to his blog comments list, without my intention and without informing me.