Convert exceptions in wrapper without using macros?

Hi!

Do you know different alternatives to convert exceptions in many
methods of some wrapper classes.

User -Wrapper classes -LibraryClasses -...

Wrapper classes catch an exception of only one type, let's call it
e.g. "InternalException_c".
There are no other types of exceptions, which should be catched /
converted.

The caught exception object should be converted e.g. to type
"ConvertedException_c".

Quite many methods of the wrapper classes should make the same
conversion.

void Wrapper::method1 ()
{
try {
...
} catch (InternalException_c& ex)
{
throw ConvertedException_c(ex);
}
}

The same applies to quite many methods, method1, method2, method3 ...,
maybe tens of different kinds of methods and in different wrapper
classes.

Quite many of those methods are planned to be inline, it is quite
mandatory, because those are called very intensively. Inline methods
are defined in the header:

class Wrapper2_c
....
inline void method2 ()
{
try {
...
} catch (InternalException_c& ex)
{
throw ConvertedException_c(ex);
}
}
....

What are the alternatives to avoid copy pasting the same try catch
clauses to many methods?
Macros might be one "alternative", but I think it should not be
thought as a real alternative in the C++ world.

I have thought to use some typedefs (caller should catch the typedef
instead of the real object),
but I think the best solution would be to convert the exception in the
methods of the wrapper classes. The caller should not make the
conversion. The only place, where the conversion should be made, are
the wrapper classes.

I have used templates, so if there could be a solution by using
templates (is there?) or by using some other techiques, please share
your information!


Thank you for your answers already in advance!

* a_agaga@yahoo.com:Macros are the best alternative.

Theoretically you can use exception specifications and std::unexpected,
but since exception specifications are generally Bad in C++, they're not
used much (except the empty no-throw exception specification), and so
you can't really expect your compiler to implement them, even in 2006.

An exception specification based approach would go like this (off the
cuff, untried code):

typedef int QuaintException;

void myXTranslator()
{
try
{
throw;
}
catch( QuantException const& x )
{
throw std::runtime_exception( "Gnurk" ); // Translated.
}
catch( std::exception const& x )
{
throw; // As-is.
}
catch( ... )
{
std::terminate(); // Not supported.
}
}

class XTrans
{
private:
std::unexpected_handler myOldHandler;

public:
XTrans()
: myOldHandler( std::set_unexpected( ::myXTranslator ) )
{}

~XTrans()
{ std::set_unexpected( myOldHandler ); }
};

...

template< typename T >
void isRaiiObject( T& ) {} // Suppress compiler silly-warnings.

void SomeWrapperClass::someMemberFunc() throw( std::exception )
{
XTrans xt; isRaiiObject( xt );

SomeSillyVendorsApi::someEvenMoreSillyFuncWithQuai ntException();
}


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thanks for the comments.

I thought about my question more,
and I think there could be at least one solution how to convert the
exception.

I could pass the method, which is wanted to be called as a pointer to
an intermediate method, which handles the conversion of the exceptions.

I could do this way:

class wrapper_c
{

int method1()
{
return intermediateMethod<int>(&wrapper_c::finalMethod1);
}

.... // more different kinds of methods...

private:

int finalMethod1()
{
// call to the library.

// IT may throw
//throw int(81);
// or return a value
//

return int (81);
}

.... // more different kinds of "final" methods...

// The intermediate method

template <class RETURN_CLASS>
RETURN_CLASS execute(RETURN_CLASS (wrapper_c::*my_memfunc_ptr)(void))
{

try {

return (this->*my_memfunc_ptr)();

} catch (int exc) {
// Convert the exception.
string excConverted;
excConverted += exc;
throw excConverted;
}


}; // wrapper_c

Or something like that.
(It would need to be implemented to every wrapper class somehow.)


Only problem is the paramaters / arguments, which are passed first to
method1, then to execute and then to finalMethod1 and from there to
library.
Does someone know how to handle the arguments?
(Some kind of a pointer to the arguments/parameters? Pass it through to
finalMethod1, and read arguments from the pointer? )

Of course I could make e.g. a struct to which I could store the values
and pass it from method1 through execute to the finalMethod1. Some sort
of templates could be used again.
But I would like to use something more convenient.
I would not like to create the structures.

I could also make several execute methods, which each take different
amount of arguments.
The types of the arguments could be handled with help of templates.
But I do not wish to create few different execute methods, because of
this.
I would just like to pass all of the arguments through one pointer, or
with some other technique, to the finalMethod1.

Therea are only void in the parameters/arguments in the code above,
but I would like to pass more parameters with different kinds of types.

And ofcourse,
method1 is/should be public:
public:

I started a new discussion about the issue here:

http://groups.google.fi/group/comp.l...a94d35c7f1c51c

Topic: Take paramaters as one pointer?

I do not know is my question understandable.