Hi Frank,
you wrote:
> > #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.
>
ok.
> > 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.
>
Hm - the intention was to make error reporting easier here. With the
assertion, one can quite easily get to the faulty code place. With an
exception, it's a bit harder - BOOST_CURRENT_FUNCTION would make that
unambiguously clear. But yeah, the size argument is clearly valid.
> 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.
>
Nope, don't think so. Lingu franca of programming is English - or do
you also want to translate IDL documentation?
> > OSL_ENSURE(false, m); \
> > return false; }
>
> parametrizing the return type might be a good idea, too.
>
One has to strike a balance. I thought about it as well, but the cases
I would have needed a different return type (mostly NULL) have been
seldom enough that I wouldn't impose the additional clutter to the
macro...
> 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?
>
Nope. Would prolly also benefit the other assertions - I'd change them
to include the function name then, as well.
> (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.)
>
So, you suggest using stuff from udkapi in osl, relying on the fact
that anyone making sensible use of them prolly implements UNO API (and
thusly already is past udkapi in the build hierarchy)?
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
