Click here to Skip to main content
15,867,906 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
After near 20 years of using MFC, I am trying to use the advantages of exceptions. I can see the value of descending the stack on error conditions, without having to pass on the error value at each level. Is there a way to do this with say error numbers, instead of having to construct CException derived classes. Surely, this mechanism depends on underlying Kernel API functions.

The DLL I am now working on has most certainly has NO GDI functions. I use MFC on this because of handy access to the Kernel32 functions. My DLL fields questions and responds, as good as it can. It is a server based DLL, which provides an error log.

It is actually quite forgiving on stack unwinding, as it is also designed with a Garbage Collector, which automatically deletes resources which are not accessed within a time frame from creation (say 15 minutes). The prototype works well with setjump but is not multi-threaded.

I am wondering about how to implement this type of behaviour with exceptions rather than setjmp.
Posted
Updated 27-May-10 23:20pm
v4

You haven't had to use CException since VC++ started supporting "real" C++ exceptions with version 2.0.

Depending on your strategy for exception handling, you can throw just about anything and catch it. In your case, you seem to want to throw an int. That should work but consider using a fuller fat class for your exceptions - std::runtime_error from the standard C++ runtime library works admirably. Even a string might be a better idea than just a raw int.

A couple of other points...

For MFC (and actually Windows programming in general), always catch any exceptions around your window procedures and you should be okay. USER doesn't like C++ exceptions wiggling through it. If you are doing multi-threaded programming, then stop all exceptions at the boundaries of your thread function.

One other point... if you're a fan of using raw pointers, then start using some form of resource management class - std::auto_ptr for VC++ 2008 and earlier, std::shared_ptr or std::unique_ptr for VC++ 2010. If you don't, then you risk leaking resources. The same goes for GDI objects - make sure they're all wrapped up in objects which delete the GDI object if the stack unwinds.

Hope that helps,
Ash
 
Share this answer
 
v2
Comments
Bram van Kampen 26-May-10 19:31pm    
Well I still use MFC42, and it still works! (despite it being disconinued) In my last (9 year old project) I never used exceptions. I never needed them, Error conditions were propagated down the line in my code. It was Hard Work, as it involved a total of 12 modules.

I want to do it different this time.
Aescleal 27-May-10 4:45am    
Well you never need to use exceptions, but they're one of the main features that make C++98 safer than C. As I said, why not throw ints if that's how you've decided is the best way to handle errors?

As a side note if I were you though I'd consider changing your compiler to VC++ 2003 or later which is a lot more standard compliant, you'll have less tears that way.
Stephen Hewitt 20-Nov-10 23:05pm    
One of the advantages to using exceptions oftern cited by advocates is that it makes it hard to ignore errors: you can ignore an error code by see what happens if you don't handle an excpetion. Handling all exceptions in you thread function negates this benifit to a degree.
Well,
As I said before, I never dealt with structured exception handeling.I'm very much a Nebe there.

what I cannot get my brain around to, is, Why must I throw a Type, and Not a Value. How do I catch an int on the other side, if I don't know it's value.

In the case I'm working at now, MFC Windows is actually a thin layer around a very much larger set of DLL's written using the 'Windows.h' File.

So, What then does the Kernel know about types used in CPP, and, how then do I catch when I just throw an int.

Thanks, and please explain.It's Me who is thick.

Regards,

Bram.
 
Share this answer
 
An CExeption derived class could have any value fields inside for the error infos,

couldn't it ? :)

(Just extend and fill yor object in its constructor. See also...[^])
 
Share this answer
 

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