Hi Thorsten,
> #define VALIDATE_AND_THROW(c, m, ifc, arg_num) if( !(c) ) { \
> OSL_ENSURE(false, m); \
this should be "OSL_ENSURE(c, m)", IMO - just in case somebody later
changes OSL_ENSURE to also display the violated condition.
> throw ::com::sun::star::lang::IllegalArgumentException( \
> ::rtl::OUString::createFromAscii(BOOST_CURRENT_FUNCTION) + \
Not sure this is a good idea - putting the current function into the
exception text. Exceptions messages might happen to be read by end users
(e.g. when displayed in StarBasic), and the function name - which is a
multiple-line complex beast when obtained via the BOOST macro - is
certainly not for end users.
Also, this would flood the release builds with a lot of strings of only
secondary interest.
I'd prefer putting the CURRENT_FUNCTION into the assertion instead.
> ::rtl::OUString::createFromAscii(",\n"m), \
> ifc, \
> arg_num ); }
>
> #define ENSURE_AND_THROW(c, m, ifc) if( !(c) ) { \
> OSL_ENSURE(false, m); \
> throw ::com::sun::star::uno::RuntimeException( \
> ::rtl::OUString::createFromAscii(BOOST_CURRENT_FUNCTION) + \
> ::rtl::OUString::createFromAscii(",\n"m), \
> ifc ); }
Of course, some kind of resource-fed versions of those would also be
nice :), with a similar reason as above: Exception messages are
potentially read by end users, and sometimes it's debatable whether they
should be localized. But that is probably another can of worms. Also,
this then would really rule out the UDK.
> #define ENSURE_AND_RETURN(c, m) if( !(c) ) { \
> OSL_ENSURE(false, m); \
> return false; }
parametrizing the return type might be a good idea, too.
>
> ---%<-----------------------------------------------------------------
>
> Is this useful, and if yes,
Yes.
> where to place it? It needs UNO, so osl is
> too low, and it currently employs boost, which afaik rules out udk...
Well, boost/current_function.hpp is really small. Nobody hinders us from
duplicating those about 10 lines (less, if we count currently supported
compilers only) of code in UDK, right?
Whether the macros are really *needed* - well, this might be debatable.
They're useful, at least, so I'm for adding them. To osl/diagnose_ex.h.
Or something like this.
(Yes, they *belong* into the UDK. We should definitely *not* introduce
yet another place of such diagnostics facilities. We already have
osl/diagnose.h, tools/debug.hxx (and, speaking strictly, the less known
tools/diagnose_ex.h), and those are already too much.)
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
