Unhandled exceptions with STL

Question

0.00/5 (No votes)

See more:

Hi everyone,

~~STL~~ C++ has a way of dealing with unexpected exceptions[^] that I would like to mimic. It's a very interesting feature that I would like to know how to implement.

The question is: how the hell do they do that? I checked the source code and it contains nothing but forward declarations, so I assume the implementation is compiled in the .dll

Anybody?

Regards

Posted 6-Jun-12 13:39pm

AndreFratelli

Updated 7-Jun-12 11:34am

Aescleal

v3

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

TRK3 · Answer 1 · 2012-06-06T13:53:00

Solution 1

This is implemented by the compiler.

It is part of the C++ standard.

It is not implemented in the current Microsoft compilers:

http://msdn.microsoft.com/en-us/library/awbt5tew(v=vs.100).aspx[^]

But looks like they will implement it soon:

http://msdn.microsoft.com/en-us/library/awbt5tew(v=vs.110).aspx[^]

There is no way to do it except at the compiler level.

Posted 6-Jun-12 13:53pm

TRK3

Comments

AndreFratelli 6-Jun-12 20:07pm

Yes, VC doesn't even support exception specification (http://msdn.microsoft.com/en-us/library/sa28fef8.aspx), so it doesn't even make sense to talk about unexpected exceptions there.

Anyway, how would you suggest that to be done at the compiler level?

TRK3 6-Jun-12 20:38pm

Imagine a try block around every function call with an explicit catch block for each specified exception type (which it just rethrows) and a generic catch block that invokes unexpected().

You can write that explicitly with the MS compilier -- so it's really just a simple matter of the compiler doing it for you implicitly (of course there is probably a more efficient way to do it -- but that gives you one idea of how it could be done).

AndreFratelli 6-Jun-12 21:04pm

That would catch the exceptions not listed in the catch blocks, not the one not listed in the function declaration.

What I make of this: it can't be done. If VS doesn't support exception specification there is no way to know if an exception is not specified. Hell, none is.

TRK3 7-Jun-12 12:59pm

Yes, but if you listed every exception that was in the function declaration -- then it would catch the exceptions that weren't listed.

So you, could do it manually (where you really cared to do it) -- or you could use modules from the LLVM to do it for you automatically. But then if you are going to do that, then just go ahead and use the Clang compiler that implements the spec. So, yeah, basically the way to do it is use a compiler that supports it.

AndreFratelli 7-Jun-12 13:44pm

Yeah, it kind of loses its purpose...

Sergey Alexandrovich Kryukov 6-Jun-12 20:26pm

Good explanation, my 5, but I cannot see the difference between two of your MSDN pages, for VS 2010 and 2012. Doesn't it look like they both implement it? I always though this feature is available -- do I miss something. With VS 2010, I can check it up.

Also, in my answer I explain how to work around it -- please see.
--SA

TRK3 6-Jun-12 20:28pm

Hmmm... I thought the 2010 link said it wasn't supported. For sure, the 2008 link says it's not implemented.

AndreFratelli 6-Jun-12 20:46pm

And I can confirm it. I tested it.

Philippe Mori 6-Jun-12 23:35pm

I don't expect Microsoft to implement exception specification soon.

In my opinion, it was an error to put them in the standard as it make maintenance harder when updated code throw new exceptions. It will also make the program somewhat slower and bigger.

And if they support them, then it would probably break compatibility with existing code and it can lead to application that stop working (because the program was wrong but it was not detected).

Using macros, metaprogramming and RTTI, it should be possible to simulate most of the standard behavior

TRK3 7-Jun-12 13:07pm

Microsoft should implement C++11 spec. And from from the Going Native webcasts, it seems like they intend to.

However giving the timing of the finalization of the spec and the release of VS, they had to pick and choose which functionality to implement in the latest release.

Exception specification is probably at the bottom of the list for all the reasons you listed.

I would expect them to implement it and give you a switch to enable or disable it.

With the LLVM compiler you could actually do some cross module analysis and statically detect potential violations of exception specification at compile time.

If MS was smart, they would actually embrace the LLVM and use that in VS 2012 -- the one thing it lacks is a good Windows back-end, they could concentrate on that and reap the benefits of all the work being done on the rest of the tool chain.

Aescleal 8-Jun-12 4:23am

I have a sneaking suspicion that MS will leave exception specifications as long as possible before implementing them. They're a deprecated feature in the new standard and no compiler of there's to date implements much of the old spec. Also Herb Sutter (one of MS's compiler architects) is a fairly vocal critic of them saying that they don't do what programmers expect them to do - either in terms of allowing more optimisations or doing static analysis of what's thrown.

TRK3 8-Jun-12 13:15pm

Yeah, you are probably right.

Now that you mention it I can't think of anything it actually buys you unless you can actually do static analysis of the whole program and validate the specifications. But that requires analysis of any libraries that you don't have source for... Even then I don't think static analysis is necessarily possible in finite time -- you can find places where the specification might be violated, but it smells a bit like the halting problem.

Aescleal · Answer 2 · 2012-06-07T03:34:00

Even if the compiler does support exception specifications you really don't want to use them.

The unexpected handler is global for a process, so there's absolutely nothing it can do that a top level exception handler can't. Nothing - not a dicky bird. In fact it's even worse than a top level exception handler because none of the destructors for objects currently in scope are guaranteed to be called. Even if you call exit() to bail out of your code destructors for automatic objects still aren't called. About the only sensible thing you can do is throw an exception that's (hopefully) of a type allowed by the specification and pray it reaches all the way to main or the thread function.

So you might as well write:

C++

int main()
try
{
    do_something();
}
catch( std::exception &e )
{
    std::cout << "Something went horribly wrong: " << e.what() << std::endl;
}
catch( ... )
{
    std::cout << "Something went horribly wrong, no idea what!" << std::endl;
}

as at least your code will clean up after itself and be in a deterministic state if you want to restart.

Sergey Alexandrovich Kryukov · Answer 3 · 2012-06-06T14:24:00

Solution 2

If you are using a compiler where unexpected handler is not implemented, you can provide a work-around on the application level. For this, it's enough to catch all exceptions on the top of the stack of each thread. It's important no to throw any exceptions in the exception handler in this case.

—SA

Posted 6-Jun-12 14:24pm

Sergey Alexandrovich Kryukov

Comments

TRK3 6-Jun-12 20:33pm

That's not really the point of unexpected is it?

Unexpected catches the exception at the point that it's first incorrectly propagated. It shows you the exact point where your specification doesn't match your implementation.

Catching something at the top level just tells you that you didn't catch it at a lower level -- it doesn't tell you if the thing that was thrown wasn't specified or not, just that you didn't catch it.

Aescleal 7-Jun-12 9:36am

It doesn't show you anything - you know nothing about the context in which it's called. All you know is that a function tried throwing something that wasn't in the exception specification.

TRK3 7-Jun-12 13:09pm

Really? Don't you at least have a stack trace at that point in a debugger?

Aescleal 7-Jun-12 17:28pm

Why would you? Not sure about all compilers but the two I know about handle exceptions on a different stack to the one they get thrown on - it's a bit hard (but probably not impossible) to unwind the stack while it's in use.

TRK3 7-Jun-12 17:38pm

Sure, you've already unwound the stack up to the point where propagating the exception becomes invalid -- so you don't have that information in the debugger (unless the compiler writer went to greate pains to give you a special expensive exception handling scheme that perserved it all) -- but you should have the information of the exact point where propagating the exception is invalid. And that's the point you want need to do something about it anyway (either handle the exception there, or specify that it can be thrown).

Aescleal 8-Jun-12 4:25am

Ah, right. That'll teach me to not read stuff properly. Sorry about that - I missed the first point you made to SA - "Unexpected catches the exception at the point that it's first incorrectly propagated." Doh.

AndreFratelli 6-Jun-12 20:51pm

I agree.