From: "William E. Kempf" <[EMAIL PROTECTED]>
> Peter Dimov said:
[...]
>
> But if every level of the call stack does such a translation, there's no
> need for who() to begin with. open_file() knows it was thrown by
> is_directory(), because it called is_directory(). change_config() knows
> it was
Peter Dimov said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>
>> Peter Dimov said:
>
> [...]
>
>> >> Knowing that "no such file or directory" was
>> >> thrown by "open_file" doesn't help the end user when the action he
>> took was to change a configuration option, for instance.
>> >
>> > The
From: "David Abrahams" <[EMAIL PROTECTED]>
>
> In general I agree with Bill. The more code gets refactored and
> encapsulated, the less useful the name of the throwing function will
> be. Take for example boost::throw_exception. I know that one doesn't
> really count, because the exception is co
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> Peter Dimov said:
> > [...] It is exceptions that
> > occur in the course in the normal operation that I'm talking about.
>
> And those, in order to be dealt with in a useful manner, have to be
> handled at a point close to the throw point, in order
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> Peter Dimov said:
[...]
> >> Knowing that "no such file or directory" was
> >> thrown by "open_file" doesn't help the end user when the action he
> >> took was to change a configuration option, for instance.
> >
> > The end user isn't interested in
Peter Dimov said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>
>> Peter Dimov said:
>
> [...]
>
>> > How would you use a call stack to generate an user friendly error
>> message?
>>
>> I wouldn't. User friendly error messages would only be generated
>> close to the throw point, where *I* hav
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> And I argue the information that who() is intended to provide is not
>> useful.
>
> I'm not sure that's true in the specific case of the filesystem lib.
I think I gave some concrete examples of why it isn't (at least general
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> Peter Dimov said:
[...]
> > How would you use a call stack to generate an user friendly error
> > message?
>
> I wouldn't. User friendly error messages would only be generated close to
> the throw point, where *I* have enough contextual informatio
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> Peter Dimov said:
>> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>> Peter Dimov said:
>>> >
>>> > The fact that who() returns a function name is not important; it is
>>> not a "mini call stack". A function name is used as a token that
>>> identifi
Peter Dimov said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> Peter Dimov said:
>> >
>> > The fact that who() returns a function name is not important; it is
>> not a "mini call stack". A function name is used as a token that
>> identifies the point of failure. What failed? An attempt to ope
From: "William E. Kempf" <[EMAIL PROTECTED]>
> Peter Dimov said:
> >
> > The fact that who() returns a function name is not important; it is not
> > a "mini call stack". A function name is used as a token that identifies
> > the point of failure. What failed? An attempt to open a file? An attempt
>
At 10:36 AM 1/14/2003, David Abrahams wrote:
>David Abrahams <[EMAIL PROTECTED]> writes:
>
>> Beman Dawes <[EMAIL PROTECTED]> writes:
>>
>>> At 03:29 PM 1/13/2003, David Abrahams wrote:
>>>
>>> >Remember that it's a bad idea to carry dynamically-allocated
>>> >state in an exception object.
>>>
>
At 04:11 AM 1/15/2003, William E. Kempf wrote:
>...
>
>But the "who" is dependent on higher level information than what's
>available to the library.
>
> Knowing that "no such file or directory" was
>thrown by "open_file" doesn't help the end user when the action he took
>was to change a configura
Peter Dimov said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>
>> Peter Dimov said:
>> > From: "William E. Kempf" <[EMAIL PROTECTED]>
>> >>
>> >> Might be true for Boost.Filesystem. The path values may be useful
>> in some cases, for instance. I'm not 100% sure about the who()
>> string, th
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> Peter Dimov said:
> > From: "William E. Kempf" <[EMAIL PROTECTED]>
> >>
> >> Might be true for Boost.Filesystem. The path values may be useful in
> >> some cases, for instance. I'm not 100% sure about the who() string,
> >> though.
> >
> > The mean
Peter Dimov said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>
>> Might be true for Boost.Filesystem. The path values may be useful in
>> some cases, for instance. I'm not 100% sure about the who() string,
>> though.
>
> The meaning of the path values is context dependent, and who() provide
David Abrahams <[EMAIL PROTECTED]> writes:
> Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 03:29 PM 1/13/2003, David Abrahams wrote:
>>
>> >Remember that it's a bad idea to carry dynamically-allocated
>> >state in an exception object.
>>
>> I wrestled with that a long time with the Filesystem
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> Might be true for Boost.Filesystem. The path values may be useful in some
> cases, for instance. I'm not 100% sure about the who() string, though.
The meaning of the path values is context dependent, and who() provides the
context, although perhap
Beman Dawes said:
> At 03:29 PM 1/13/2003, David Abrahams wrote:
>
> >Remember that it's a bad idea to carry dynamically-allocated state in
> an exception object.
>
> I wrestled with that a long time with the Filesystem Library, and
> finally ignored it. The advice is good in general, but there j
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 03:29 PM 1/13/2003, David Abrahams wrote:
>
> >Remember that it's a bad idea to carry dynamically-allocated state in
> >an exception object.
>
> I wrestled with that a long time with the Filesystem Library, and finally ignored
>it. The advice is
> go
From: "Beman Dawes" <[EMAIL PROTECTED]>
>
> Operating systems provide useful information (error descriptions
translated
> into the local language, for example) which are easy to supply as readable
> strings as part of the exception, and hard for users to supply (because
the
> user code would be non
At 03:29 PM 1/13/2003, David Abrahams wrote:
>Remember that it's a bad idea to carry dynamically-allocated state in
>an exception object.
I wrestled with that a long time with the Filesystem Library, and finally
ignored it. The advice is good in general, but there just didn't seem to be
any way
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams said:
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> People said they wanted it, and the cost is low (one int). I think
>> Greg is rig
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
>>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>>
> People said they wanted it, and the cost is low (one int). I think
> Greg is right that they wanted to attempt system-dependent
> re
At 03:11 AM 1/14/2003, William E. Kempf wrote:
>Stefano Delli Ponti said:
>> From: "William E. Kempf" <[EMAIL PROTECTED]>
>>> David Abrahams said:
>>> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>> >
>>> >>> People said they wanted it, and the cost is low (one int). I think
>>> Greg is righ
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
People said they wanted it, and the cost is low (one int). I think
Greg is right that they wanted to attempt system-dependent recovery.
>>>
>>> Well, I can agree th
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> If the exception type doesn't fold multiple errors into a single unit,
> there's no need for the error code in this situation. RTTI will provide
> the same capabilities, even if you don't want to have seperate catch
> clauses.
It won't, unless you
Stefano Delli Ponti said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> David Abrahams said:
>> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> >
>> >>> People said they wanted it, and the cost is low (one int). I think
>> Greg is right that they wanted to attempt system-dependent
>> reco
From: "William E. Kempf" <[EMAIL PROTECTED]>
> David Abrahams said:
> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >
> >>> People said they wanted it, and the cost is low (one int). I think
> >>> Greg is right that they wanted to attempt system-dependent recovery.
> >>
> >> Well, I can agree
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>>> People said they wanted it, and the cost is low (one int). I think
>>> Greg is right that they wanted to attempt system-dependent recovery.
>>
>> Well, I can agree that the cost is low... so I won't argue too much
>> abou
> Beman Dawes said:
[...]
> > The idea of mandatory "options" is new to me. Wonders never cease.
Actually the idea isn't that new. An example of a mandatory C++ option is,
for example, function template partial ordering. The compilers have to
support it in theory, but in practice some don't, and
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> People said they wanted it, and the cost is low (one int). I think Greg
>> is right that they wanted to attempt system-dependent recovery.
>
> Well, I can agree that the cost is low... so I won't argue too much about
> including it. I just want t
Beman Dawes said:
> At 11:52 AM 1/11/2003, Alexander Terekhov wrote:
> >
> >"William E. Kempf" wrote:
> >[...]
> >> > There is some chance you might talk me into accepting two flavors
> of threading for the Standard - full threads and threads-lite in
> effect. But picking and choosing between
Beman Dawes said:
> At 05:15 PM 1/10/2003, William E. Kempf wrote:
>
> >>... what() // from std::runtime_error. Implementation
> provides
> >> // a very explicit message, including who(),
> path1(), // path2(), and message reported by O/S
> (which is // subject to local
From: "Martin Brown" <[EMAIL PROTECTED]>
> Hi,
>
> I would second the approach below. If I can get to
> the native error code, then I can use FormatMessage()
> or strerror() to get to the platform error message,
> localised if necessary. I am not so interested in
> the name of the function thro
At 11:52 AM 1/11/2003, Alexander Terekhov wrote:
>
>"William E. Kempf" wrote:
>[...]
>> > There is some chance you might talk me into accepting two flavors of
>> > threading for the Standard - full threads and threads-lite in effect.
>> > But picking and choosing between four or five optional threa
At 05:15 PM 1/10/2003, William E. Kempf wrote:
>>... what() // from std::runtime_error. Implementation provides
>> // a very explicit message, including who(), path1(),
>> // path2(), and message reported by O/S (which is
>> // subject
Hi,
I would second the approach below. If I can get to
the native error code, then I can use FormatMessage()
or strerror() to get to the platform error message,
localised if necessary. I am not so interested in
the name of the function throwing the exception - I
tend to use a logger with a st
Title: RE: Re: [boost] Re: Next revision of boost::thread & OS error code.
From: William E. Kempf [mailto:[EMAIL PROTECTED]]
>> ... what() // from std::runtime_error. Implementation provides
>> // a very explicit message, including who(), path1(),
>>
boost-bounces@list Subject: Re: Re: [boost] Re: Next
revision of boost::thread & OS error code.
At 03:15 PM 1/10/2003, William E. Kempf wrote:
>> From: Beman Dawes <[EMAIL PROTECTED]>
>> At 11:18 AM 1/10/2003, William E. Kempf wrote:
>> >> From: David Abrahams <[EMAIL PROTECTED]>
>> >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> >> >> From: Martin Brown <[EMAIL PROTECTED]>
>> >> >>
> From: Beman Dawes <[EMAIL PROTECTED]>
> At 11:18 AM 1/10/2003, William E. Kempf wrote:
> >> From: David Abrahams <[EMAIL PROTECTED]>
> >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >> >> From: Martin Brown <[EMAIL PROTECTED]>
> >> >>
> >> >> 2. The user needs a localised error message.
> From: [EMAIL PROTECTED]
>
> Just a query from a user.
>
> If a localized error message exists, it will very probably be keyed to an
> OS error code. *IF* an OS error code were available at the point of
> failure, would it be possible and/or advisable to include it as part of the
> exception pa
At 02:53 PM 1/10/2003, Beman Dawes wrote:
>...
>
>Some platforms are so limited they fall outside the standard's "hosted" category, and
>we don't have to worry about them.
>
>Some platforms are fully featured, so again no worries.
>
>What you are worrying about seems to me to be platforms which mi
> From: Beman Dawes <[EMAIL PROTECTED]>
> At 07:38 AM 1/10/2003, William E. Kempf wrote:
>
> >I'm not enough of an expert to say, but I know the issue isn't that
> >simple. Let's look just at the priority scheduling for a second.
> >
> >The single largest request I've had for an addition to Bo
At 11:18 AM 1/10/2003, William E. Kempf wrote:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> >> From: Martin Brown <[EMAIL PROTECTED]>
>> >>
>> >> 2. The user needs a localised error message.
>> >
>> > Is the textual representation of the except
At 07:38 AM 1/10/2003, William E. Kempf wrote:
>I'm not enough of an expert to say, but I know the issue isn't that
>simple. Let's look just at the priority scheduling for a second.
>
>The single largest request I've had for an addition to Boost.Threads is
to
>add priority support. It's absolute
mailing list
<[EMAIL PROTECTED]>
Sent by: cc:
boost-bounces@list Subject: Re: Re: [boost] Re: Next
revi
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >> From: David Abrahams <[EMAIL PROTECTED]> What
> >> information do you *have* at the point of detection?
> >
> > Depends on numerous factors, such as the platform it's
> > running on and how much time yo
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]> What
>> information do you *have* at the point of detection?
>
> Depends on numerous factors, such as the platform it's
> running on and how much time you want to spend
> gathering information. We could pro
> From: David Abrahams <[EMAIL PROTECTED]>
> What information do you *have* at the point of detection?
Depends on numerous factors, such as the platform it's running on and how much time
you want to spend gathering information. We could provide a stack trace, a memory
dump, a listing of running
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> >> From: David Abrahams <[EMAIL PROTECTED]>
>> >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> >>
>> >> >> From: Martin Brown <[EMAIL PROTECTED]
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
> >> From: David Abrahams <[EMAIL PROTECTED]>
> >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >>
> >> >> From: Martin Brown <[EMAIL PROTECTED]>
> >> >>
> >> >> 2. The user needs a localised error
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> >> From: Martin Brown <[EMAIL PROTECTED]>
>> >>
>> >> 2. The user needs a localised error message.
>> > Is the textual representation of the exceptio
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
> >> From: Martin Brown <[EMAIL PROTECTED]>
> >>
> >> 2. The user needs a localised error message.
> >
> > Is the textual representation of the exception name
> > enough? If not, how do you propose a li
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: Martin Brown <[EMAIL PROTECTED]>
>>
>> 2. The user needs a localised error message.
>
> Is the textual representation of the exception name
> enough? If not, how do you propose a library provide
> such a localised error message?
I will wei
> From: Martin Brown <[EMAIL PROTECTED]>
>
> Hi,
>
> Regarding the OS error code / exception type debate; I
> may have missed something here, so apologies if I
> have. Speaking as a user of your wonderful
> libraries:
>
> 1. I need all the data available - the error may be
> happening on a com
> From: Beman Dawes <[EMAIL PROTECTED]>
> At 02:59 PM 1/9/2003, William E. Kempf wrote:
> >> From: Beman Dawes <[EMAIL PROTECTED]>
> >> I'm not saying Boost.Threads should take exactly the same approach,
> >> but I'd rather not see a lot of optional/conditional features to
> >> support operatin
From: "Beman Dawes" <[EMAIL PROTECTED]>
> People will be afraid to use Boost.Threads if they think that even on a
> fully-feature operating system some Boost.Threads features may not be
> available, or the features may be available with one compiler but not
> another.
This is exactly my point.
Mai
At 02:59 PM 1/9/2003, William E. Kempf wrote:
>> From: Beman Dawes <[EMAIL PROTECTED]>
>> I'm not saying Boost.Threads should take exactly the same approach,
>> but I'd rather not see a lot of optional/conditional features to
>> support operating systems other than those two O/S families.
>
>Well,
From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > From: "William E. Kempf" <[EMAIL PROTECTED]>
> > >
> > > OK, I've been looking at boost::filesystem_error. Here's my thoughts:
> > >
> > > boost::filesystem_error could be benefited by splitting it up into
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "William E. Kempf" <[EMAIL PROTECTED]>
> > > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > > > (And is it useful to distinguish between memory and other resource
> > > errors?)
> > >
> > > This, I have no ready answer for... but "when in doubt, do wha
From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > > (And is it useful to distinguish between memory and other resource
> > errors?)
> >
> > This, I have no ready answer for... but "when in doubt, do what POSIX
does."
>
> Why (in regards to "do what POSIX d
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "William E. Kempf" <[EMAIL PROTECTED]>
> > > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > > From: "William E. Kempf" <[EMAIL PROTECTED]>
> > > >
> > > > OK, I've been looking at boost::filesystem_error. Here's my thoughts:
> > > >
> > > > boost::fil
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "William E. Kempf" <[EMAIL PROTECTED]>
> >
> > OK, I've been looking at boost::filesystem_error. Here's my thoughts:
> >
> > boost::filesystem_error could be benefited by splitting it up into more
> > exception types. I know this was suggested in
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> OK, I've been looking at boost::filesystem_error. Here's my thoughts:
>
> boost::filesystem_error could be benefited by splitting it up into more
> exception types. I know this was suggested in the review, but don't know
> what the plan was in rega
At 01:32 PM 1/9/2003, William E. Kempf wrote:
>> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
>> > From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > > > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
>> > > > From: "David Abrahams" <[EMAIL PROTE
> From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> > From: "William E. Kempf" <[EMAIL PROTECTED]>
> > > > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> > > > From: "David Abrahams" <[EMAIL PROTECTED]>
> > > > > "William E. Kempf" <[EMAIL PROTECT
> From: Beman Dawes <[EMAIL PROTECTED]>
> At 11:44 AM 1/9/2003, William E. Kempf wrote:
>
> >As for conditional compilation... the Boost.Filesystem stuff has no
> >need for this, while Boost.Threads has a very definate need.
>
> The reason that Boost.Filesystem doesn't have conditional compilat
At 11:44 AM 1/9/2003, William E. Kempf wrote:
>As for conditional compilation... the Boost.Filesystem stuff has no
>need for this, while Boost.Threads has a very definate need.
The reason that Boost.Filesystem doesn't have conditional compilation is
that a design decision was made to limit the l
> From: Alexander Terekhov <[EMAIL PROTECTED]>
> "William E. Kempf" wrote:
> [...]
> > > I think that a reasonable requirement that we already mentioned several
> > > times is that the ID should be CopyConstructible, Assignable and
> > > LessThanComparable, for use in sets/maps.
> >
> > This misse
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > From: David Abrahams <[EMAIL PROTECTED]>
>> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> > >> From: David Abrahams <[EMAIL PROTECTED]>
>> > >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> > >>
> From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> From: "William E. Kempf" <[EMAIL PROTECTED]>
> > > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> > > From: "David Abrahams" <[EMAIL PROTECTED]>
> > > > "William E. Kempf" <[EMAIL PROTECTED]> writes:
> > > >
> > > > > That's a good idea. So wo
From: "Peter Dimov" <[EMAIL PROTECTED]>
> I don't see any drawback in throwing something derived from
> std::runtime_error, and not std::runtime_error itself. This lets you
provide
> more information for clients that catch(thread_error) and still lets
others
> catch(std::runtime_error).
>
> As for
From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: David Abrahams <[EMAIL PROTECTED]>
> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
> > >> From: David Abrahams <[EMAIL PROTECTED]>
> > >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> > >>
> > >> > That's a good idea. So would users pref
From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> > From: "David Abrahams" <[EMAIL PROTECTED]>
> > > "William E. Kempf" <[EMAIL PROTECTED]> writes:
> > >
> > > > That's a good idea. So would users prefer new exception types here,
> > > > or should I
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >> From: David Abrahams <[EMAIL PROTECTED]>
> >> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >>
> >> > That's a good idea. So would users prefer new exception types here,
> >> > or should I use the
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> > That's a good idea. So would users prefer new exception types here,
>> > or should I use the std:: exceptions?
>>
>> IMO, it's always safer to use
> From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> From: "David Abrahams" <[EMAIL PROTECTED]>
> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >
> > > That's a good idea. So would users prefer new exception types here,
> > > or should I use the std:: exceptions?
> >
> > IMO, it's always saf
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
> > That's a good idea. So would users prefer new exception types here,
> > or should I use the std:: exceptions?
>
> IMO, it's always safer to use an exception type which provides
> more-specific infor
From: "David Abrahams" <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
> > That's a good idea. So would users prefer new exception types here,
> > or should I use the std:: exceptions?
>
> IMO, it's always safer to use an exception type which provides
> more-specific info
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> That's a good idea. So would users prefer new exception types here,
> or should I use the std:: exceptions?
IMO, it's always safer to use an exception type which provides
more-specific information.
--
David Abrahams
[EM
> From: Alberto Barbati <[EMAIL PROTECTED]>
> William E. Kempf wrote:
> > * Are there concerns about using conditional compilation and optional portions of
>the library, as POSIX does? I believe this is the only way Boost.Threads and the C++
>standard will be able to provide "portable" threading
83 matches
Mail list logo
