Meaning of exit codes in my C++ MFC program

I am developing a dialog-based application in MFC using C++.   I am using Visual Studio 2013.  During debugging activities, I am used to seeing messages like "The thread 0x1648 has exited with code 20 (0x14)".  Messages like this appear in the "Output" window of Visual Studio, after the program has terminated.  I have poked around and come to believe that this exit code (20) is OK for a dialog based application.  But today I see this message: "The thread 0x568 has exited with code 32812 (0x802c)."  So I thought something went wrong.  

But three things puzzle me.  1)  There is no other indication that anything was wrong (no failures, exceptions, leaks, etc., reported).  2) I went back to a version of my program from a couple of weeks ago and it did the same thing.  In fact I re-ran about a dozen versions stretching back a month and they all had the same exit code.  This is really odd because they did not have that exit code at the time they were being developed and tested.  2) When I research exit codes, I started to wonder if it means anything at all.  Apparently my application sets this code in some manner (I'm not doing it explicitly).  

So, can you tell me if this means anything is wrong?  Is there a way to determine what exit code 32812 means?  Why does this sort of appear to be dependent not upon my application, but on my machine (i.e., the same program had an exit code of 20 a week ago).

Thanks very much for unraveling this mystery for me.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

>>  Is there a way to determine what exit code 32812 means?

If you have the source code - yes ;o)

Seriously, that can be any arbitrary, application-specific value that is passed to 'ExitThread()' ( or returned from the Thread function, which is documented as "The function should return a value that indicates its success or failure.". AFAIK there is no standardized list of codes, if you are lucky, values from 'winerror.h' are used.
debrunsonAuthor Commented:
Unforunately I do not know where or when my program sends information to ExitThread().  I do not have this instruction anywhere in my solution.

However there is new information to further expose my ignorance.  When I click the "X" in the upper right corner, I get an exit code of 20, which is what I have come to assume is normal.  But when I click my File/Exit menu item, I get the exit code 32812.  Perhaps you can explain something to me...

Long ago I overrode the OnClose() handler, which fires when the "X" is clicked.  This handler calls a cleanup method, then ends by calling the base class handler CDialog::OnClose();

However when File/Exit is clicked, I call the same cleanup method, but I then end with EndDialog(IDOK).  

I do this because I was under the impression that I should not send Windows system messages in my code, i.e. just as I would not send an "OnPaint()" message myself, I would not send an "OnClose()" message.  I similarly believe that I should not call the OnClose() handler myself.  So, I seem to be stuck with closing the app using CDialog::OnClose() on one hand, or EndDialog(IDOK) on the other.  Maybe neither is wrong and the exit code is just a reflection of the two different methods.

Your thoughts?
It *could* well be like that, yes that's nothing I would rely on. MFC does not create a separate thread to handle dialogs and/or windows, it adheres strictly to a 'one single GUI thread' philosphy.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

most developers would return 0 on success of a thread and error code on failure.

for handler functions they either are void or return 1 if they handled the messages or 0 if they should passed to the next handler (if any).

debrunsonAuthor Commented:
With your input I tried returning TRUE from my main app's InitInstance() routine.  This then returns an exit code of 0x0 regardless of how I close the dialog.  Possibly I am starting to understand.  So if an error bubbles up from the dialog and returns an error code to the main app, I can return from the main app with that error code to use in my diagnostics.  Does that sound right?

However someplace I read that I was supposed to return FALSE from the main app "so that we exit the  application, rather than start the application's message pump."  Does that make any sense?  Or is it OK to return TRUE from the main application?

Thank you.
So if an error bubbles up from the dialog and returns an error code to the main app, I can return from the main app with that error code to use in my diagnostics.  Does that sound right?
yes. if you started the application in a batch file or from command window, any exit code different from 0 would be assigned to ERRORLEVEL what could be checked by command like 'if errorlevel 1 ...'. similar any launcher application can programmatically check the exit code of a launched and terminated program. on success the program should return 0 to keep it simple. so it rarely makes sense to return a dialog return code (for example IDCANCEL == 2) as exit code of the application as this is not an error. on the other hand it would make much sense to return a non-zero if the database could not be opened or the license has expired.

debrunsonAuthor Commented:
Thanks very much Sara.  I think I understand.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.