From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
I see, ambiguous usage of user. Let's rephrase: in most cases the
what() string is supplied by the throw point, not the catch point,
right? I.e. library authors decide what to return from what(), library
users do not.
Except
From: David Bergman [EMAIL PROTECTED]
I have always interpreted non-localized as comprehensible to some 60%
of scientifically inclined Americans ;-)
Looks like a joke but hides a relevant point. Sometimes you need to
localize to plain (nontechnical) English, too.
mailing list
Subject: Re: [boost] Do we need a boost_exception class or idiom?
From: David Bergman [EMAIL PROTECTED]
I have always interpreted non-localized as comprehensible to some
60%
of scientifically inclined Americans ;-)
Looks like a joke but hides a relevant point. Sometimes you need
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
There are workarounds for that problem. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
Thanks for the link. Comments:
* I personally
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
In fact,
in most cases they are user supplied, instead of implementation
supplied.
User supplied what() strings? In most cases?
Every standard exception from logic_error or
]
Subject: Re: [boost] Do we need a boost_exception class or idiom?
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
David Abrahams said:
[...]
std::mapchar const*, std::string, compare_cstring?
This assumes that the what() strings are all unique,
Show me another solution
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
In fact,
in most cases they are user supplied, instead of implementation
supplied.
User supplied what() strings? In most cases?
Every standard exception from
Fernando Cacciola [EMAIL PROTECTED] writes:
I'm not sure if a boost exception class is *needed*, but I see no problem in
having one.
Anyway, IIF such an exception class is defined, I *strongly* encourage (as I
did in the past) that it provides:
virtual void raise() const
{
#ifndef
William E. Kempf [EMAIL PROTECTED] writes:
Fernando Cacciola said:
I'm not sure if a boost exception class is *needed*, but I see no
problem in having one.
Anyway, IIF such an exception class is defined, I *strongly* encourage
(as I did in the past) that it provides:
virtual void raise()
Beman Dawes [EMAIL PROTECTED] writes:
The bigger issue is whether or not Boost should have a usual way of
defining error exceptions thrown by Boost libraries
Probably not; std::exception works well enough.
with raise() being one of the issues to be dealt with.
Definitely not. That's not a
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
Fernando Cacciola said:
template typename T, typename P1
void raise(const P1 p1)
{
#ifndef BOOST_NO_EXCEPTIONS
throw T(p1);
#endif
}
// other such overloads if needed
void foo()
{
raisestd::logic_error(my logic
William E. Kempf [EMAIL PROTECTED] writes:
There are workarounds for that problem. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
Thanks for the link. Comments:
* I personally don't agree with the rationale that not throwing
bad_alloc when constructing from a string is
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
There are workarounds for that problem. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
Thanks for the link. Comments:
* I personally don't agree with the rationale that not throwing
bad_alloc when
13 matches
Mail list logo
