Click here to Skip to main content
15,887,746 members
Please Sign up or sign in to vote.
4.20/5 (3 votes)
See more:
Hi, just curious. Imagine my app throws some exception, e.g., throw "error";
-- if this is not caught anywhere, this will result in a crash in the end right?
Posted

Yes your program will crash but exactly how it will go out depends on a couple of things.
You're writing C++ but on what OS and with what framework?

For example on Windows some frameworks will install an unhandled exception filter for you and some won't.
Back in the day I don't think MFC did but now it may. This means you'll get a crash dialog that says you had an unhandled exception and may even give the user the opportunity to attempt to continue execution which is generally a bad idea. Otherwise the framework may give the user the opportunity to report the crash to the developer at this point which is possibly a good idea.
In most cases you can of course install your own unhandled exception filter overriding any provided for you. In all cases however you need to be sure of what will happen so you can protect the users data. The advice as ever is to know your enemy. :-)
 
Share this answer
 
Comments
nv3 13-Jun-13 6:00am    
Thorough answer. +5
VICK 13-Jun-13 6:08am    
my 5 for you.. well explained.
:)
zlogdan 13-Jun-13 11:42am    
My 5, excellent! Congrats! If possible, please expand this to an article!
Matthew Faithfull 13-Jun-13 11:55am    
Thank you and Khan Ji and nv3 as well. I've been digging into Windows bootstrapping including setting up exception handling for years. I'm working on it but the article is a way off yet. I have at least 2 more QOR articles to do before I can introduce Windows specific stuff, one is in the editing stage but the other is big and not even started yet so it will be a few months at least.
If you don't catch the exception then it is unwinds even the main()/WinMain() call of your program and the exception gets caught by the runtime library that simply can not result in a happy end.
 
Share this answer
 
Comments
Matthew Faithfull 13-Jun-13 6:24am    
An interesting point. Does the MSVCRT runtime catch C++ exceptions or only Structured Exceptions? Source check needed to resolve that I think, I know it has an SEH catch(...) but I'm not convinced about C++ exceptions.
pasztorpisti 13-Jun-13 6:51am    
In case of uncaught c++ exceptions the crt has to call your unexpected exception handler (if set). If you haven't set up your exception handler then the default behavior is calling terminate that calls the terminate handler. If you havent set up your terminate handler then the default behavior is calling abort().
http://www.cplusplus.com/reference/exception/set_unexpected/
http://www.cplusplus.com/reference/exception/set_terminate/

Personally my favorite solution to the problem is placing a generic exception handler at the root of the call tree. Handling exceptions/crashes per-thread is another challenge.
pasztorpisti 13-Jun-13 7:42am    
With Visual Studio 2010 I couldn't get set_unexpected() work, but the fact that letting an exception to unroll main() still holds - it doesn't really matter whether the crt handles it or not.
Matthew Faithfull 13-Jun-13 8:54am    
You're right of course. Thanks for the clarification and yes threads are a another issue.

The only time I can see where the CRT behaviour might matter is that if the CRT handles the exception then static variable destructors will be called. If it doesn't they won't.
pasztorpisti 13-Jun-13 11:29am    
Static variable constructors are also interesting. If you load for example a DLL then the static ctors are executed before your LoadLibrary() call returns and DLL loading can fail silently/misteriously if you crash in your static ctors...
Yes, as you might easily verify yourself.
 
Share this answer
 
Comments
Dan page 13-Jun-13 3:34am    
I might verify it Once - which does not mean that will happen always, that is why I asked.
CPallini 13-Jun-13 3:51am    
Well, computer programs behaviour is (usually :-) ) quite deterministic. However, if you need the comfort of the documentation, here you are:
http://msdn.microsoft.com/en-us/library/ac9f67ah(v=vs.110).aspx

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900