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

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

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