Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

ANSI2000

Exception handling

This topic is 5958 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What would be the best way to create Exception handling in C++? Create exception classes internaly within the class you want to catch exceptions? Or just create them as there own...

Share this post


Link to post
Share on other sites
Advertisement
I''d say it depends. If you have a general type of exception that may occur anywhere in your project, then you''ll want its definition to be "global" while an exception that can only occur within a particular class should be declared as a private class.

But I agree that you should derive from std::exception or one of its derived classes and handle those at the appropriate level.

I wanna work for Microsoft!
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
I''d go for a public nested class, or it will be hard to catch outside the class...

Pack __LINE__ and __FILE__ into the exception show-how, this provides nice & clear tracking of the source of the exception if you catch it at a higher level. Provide a method to write over the line & file, that way the you/the user can be pointed to your/their line of code that threw the exception, instead of some line buried in the exceptional class, or worse the line/file it was caught at.

I use an Error class in each of my namespaces that holds an error code, can resolve to a description, hold the line & file of the source of the expcetion, and an additional description string. Expensive, but very detailed and useful.

Something like:
m_Server.Listen(bindAddress).Where(__LINE__, __FILE__).Throw();

Listen returns a Socket::Error, Where is a method of Error, that returns a Error& to *this, which allows you to chain the calls. Throw only really throws on failure.
In my actual code I use a macro for Where(...).Throw(); so I don''t have to type all that everytime.

Letting the user decide if/when it throws is useful. If they anticipate failure, then can check error codes and retry. If they expect it to succeed, then they can make it throw. The disadtantage is they can forget to check the code or throw, then there''s an error that''s not dealt with, which was one of the thing exceptions were suppose to avoid.

If you throw C++ exceptions in your code, then it can only be used in projects that have C++ exceptions enabled. This is not permisable in a number of situations like in kernel-land, in a COM component, with a Office add-in, nor in a directshow filter. There''s probably lots more situations. IIRC, there''s some issues with throwing/catching between an app and a dll as well, though I don''t recall what''s allowed when...

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

Share this post


Link to post
Share on other sites
Why would I want to derive from the std::exception? I was gona write my own base exception class... Unless std::exception has a whole bunch of nifty features....

Magmai __FILE__, __LINE__ Are those keywords or just flags you created in your code...

Also I will use exceptions only. Am not doing com nor amd I doing Office or direct show filters, only for my game engine... And you can catch com exceptions... Unless they are API specific, because at work with ADO I catch com exceptions...

Share this post


Link to post
Share on other sites
Derive from std::exception because it''s standard. It makes your code compatible with other code that catches standard exceptions, it makes your code readable to those who use standard exceptions, and so on. (Why am I lecturing about standards to someone who has ANSI in their username?)

Share this post


Link to post
Share on other sites
I was just wondering thats all...

I guess the STD exception also offers call stack tracing etc?

And just because it is called "standard" template library, doesnt mean it is standard and every one is using it But what ever. I don''t have a problem with it and I use it, so I will derive my exceptions from std::exception...

Share this post


Link to post
Share on other sites
The idea is, you can catch(std::exception& e) at the highest level in your code, and catch any, every, and all C++ exceptions, and everyone contains all the information specified by std::exception. So you can write error tracing code once in one spot and be done with it.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

Share this post


Link to post
Share on other sites
quote:
Original post by ANSI2000
Also I will use exceptions only. Am not doing com nor amd I doing Office or direct show filters, only for my game engine... And you can catch com exceptions... Unless they are API specific, because at work with ADO I catch com exceptions...


The import directive creates an exception throwing wrapper around all COM calls. All COM functions return an HRESULT. Every single one, no exceptions

If you specify raw_interfaces_only after the import directive, it will not produce a wrapper. Alternatively, if you do use the wrapper class, you can call raw_xxxx and skip the exception-baking code and get the HRESULT.

To further emulate exceptions, there''s an ISupportError (or something like that) interface which you can query/call for additional information if the COM object "excepts" (by returning E_FAIL or the like).

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!