Re: Re: [boost] Re: Next revision of boost::thread &OS error code.
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 locale on some O/S's. > >> > >>int native_error() const; > >>// a return of 0 implies a library (rather than system) error > >> > >>error_code error() const; // filesystem defined error code > >> > >>const std::string & who() const; // name of func throwing > >exception > >> > >>const path & path1() const; // argument 1 to func; may be > empty() > >>const path & path2() const; // argument 2 to func; may be > empty() > >> > >> That's pretty heavyweight, but each function has important uses. > > > >This description brings a better understanding than what I had > previously, > >but doesn't fill in all the gaps. > > > >What's the purpose of a non-native error code? > > It is useful for those who want a portable, more detailed breakdown of > what caused the error. The alternative was no non-native error code, > but instead providing one exception class for each of what are now > error codes. That's what I'm proposing. A seperate exception for each error condition. Under that scheme, I'm not sure I see any use for a code, native or not. > > For that matter, if what() > >includes a translated message for the error code, what purpose is > there > for > >the native error code? > > 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 to feel comfortable with the rationale. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
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 throwing the exception - I > tend to use a logger with a stack-trace built in. The purpose of the function name is to act as a portable unique identifier that answers the "what failed?" question; the error code answers the "why did it fail?" question. Both parts are needed, in general, to construct an error message. I.e. who() == "std::fopen" path1() == "foo.txt" error() == ENOENT (or "ENOENT") Sample message: "foo.txt": Open error: No such file or directory Depending on the situation, one of the "what"/"why" pieces can be encoded in the exception type (open_error or file_not_found for the above), but it's still useful to have a common mechanism to obtain them from a single catch clause. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
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 locale on some O/S's. >> >>int native_error() const; >>// a return of 0 implies a library (rather than system) error >> >>error_code error() const; // filesystem defined error code >> >>const std::string & who() const; // name of func throwing >exception >> >>const path & path1() const; // argument 1 to func; may be empty() >>const path & path2() const; // argument 2 to func; may be empty() >> >> That's pretty heavyweight, but each function has important uses. > >This description brings a better understanding than what I had previously, >but doesn't fill in all the gaps. > >What's the purpose of a non-native error code? It is useful for those who want a portable, more detailed breakdown of what caused the error. The alternative was no non-native error code, but instead providing one exception class for each of what are now error codes. > For that matter, if what() >includes a translated message for the error code, what purpose is there for >the native error code? 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. Note that there is no requirement on what(). As a QOI I tried to deliver a very informative message, but don't want to try to mandate that. Also, whether the localized message actually is in the right language for the user depends on a lot more than what the O/S thinks is the right locale. >The thread will always be the current thread, so there's no need to carry >that payload. Duh! --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
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 stack-trace built in. The parameters are nice if a lightweight mechanism can be found for recording them. As regards error code collisions, library and OS errors etc: I think there is a split in the way exceptions are used. Assuming that the OS is complex, thus there are many possible failure conditions, _any_ error code could returned by _any_ API function. If the code is trying to recover from this, then all we (programmers) are interested in are the broad categories of the error, so we can code appropriate recovery actions. If we are not interested in recovering (e.g. we didn't expect anything to go wrong, so we need to know if it did) then all we want to do is dump as much information in front of the user and rollback the operation. I would say that exception types should be used for categorising exceptions for the purposes of recovery, but that the OS error code should be available when we have to present the information to the user. A sub-class could be used to separate library errors from OS errors. Personnally, I have never found what() much use for anything except debugging. The standard does not promise anything about its contents; and even if the string is useful, it would have to be parameterised, translated and encoded appropriately for word-wide use - non trivial and a huge maintenance effort. Thanks - I really appreciate the work you are doing, Martin Beman Dawes wrote: Peter Dimov and I went back and forth about this for the filesystem library and decided: ... 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 locale on some O/S's. int native_error() const; // a return of 0 implies a library (rather than system) error error_code error() const; // filesystem defined error code const std::string & who() const; // name of func throwing exception const path & path1() const; // argument 1 to func; may be empty() const path & path2() const; // argument 2 to func; may be empty() That's pretty heavyweight, but each function has important uses. For Boost.Threads, path1() and path2() obviously don't apply, but I wouldn't be surprised if a string identifying the thread in some way wasn't a possible need. --Beman __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: [boost] Re: Next revision of boost::thread & OS error code.
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(), >> // path2(), and message reported by O/S (which is >> // subject to locale on some O/S's. >> >> int native_error() const; >> // a return of 0 implies a library (rather than system) error >> >> error_code error() const; // filesystem defined error code >> >> const std::string & who() const; // name of func throwing exception >> >> const path & path1() const; // argument 1 to func; may be empty() >> const path & path2() const; // argument 2 to func; may be empty() >> >> That's pretty heavyweight, but each function has important uses. > >This description brings a better understanding than what I had >previously, but doesn't fill in all the gaps. > >What's the purpose of a non-native error code? For that matter, if >what() includes a translated message for the error code, what >purpose is there for the native error code? When there is not a one to one mapping of library errors and native errors having both may be useful for platform specific recovery. >> For Boost.Threads, path1() and path2() obviously don't apply, but I >> wouldn't be surprised if a string identifying the thread in some way >> wasn't a possible need. > >The thread will always be the current thread, so there's no need to >carry that payload. It could be potentially be useful in a scheme where exceptions can be propagated across threads to the joiner. Glen
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
I apologize. I believe I did not express my query clearly. I didn't mean to suggest that the OS error code be used to define, name or construct an exception. Those issues are WAY beyond my ability to make any meaningful contribution to this thread. On the other hand, *IF* an OS error code were available and was captured at the point of failure and "tucked away", it could be retrieved for use by an exception handler (e.g., e.os_error()). As David Abrahams pointed out in an earlier post: I will weigh in here with one strong opinion: producing localized error messages should not be the job of the exception object or the code which throws it. Error message formatting and localization should happen after exceptions are caught. WRT the code vs the message, my earlier post noted that the localized error messages are generally keyed to an OS error code. That claim was not accurate. I believe such messages are generally accessed by a compound key typically consisting of OS code and language identifier. Depending upon the program, the language identifier may or may not correspond to that of the OS as installed. The exception handler would best be able to select the most appropriate language. "William E. Kempf" <[EMAIL PROTECTED]> To: Boost mailing list <[EMAIL PROTECTED]> Sent by: cc: boost-bounces@list Subject: Re: Re: [boost] Re: Next revision of boost::thread & OS error code. s.boost.org 01/10/2003 02:09 PM Please respond to Boost mailing list > 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 payload for transport to the handler? Why the code instead of the message? How do you deal with the issues I pointed out in my other posts, such as overlapping values and the need for non-OS error codes? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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]> >> >> >> >> >> >> 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 weigh in here with one strong opinion: producing localized >> >> error messages should not be the job of the exception object or the >> >> code which throws it. Error message formatting and localization >> >> should happen after exceptions are caught. >> > >> >Full agreement. But what (if anything) must the exception object >> >provide in order for the exception handlers to be able to format >> >a localized message? >> >> Peter Dimov and I went back and forth about this for the filesystem library >> and decided: >> >>... 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 locale on some O/S's. >> >>int native_error() const; >>// a return of 0 implies a library (rather than system) error >> >>error_code error() const; // filesystem defined error code >> >>const std::string & who() const; // name of func throwing exception >> >>const path & path1() const; // argument 1 to func; may be empty() >>const path & path2() const; // argument 2 to func; may be empty() >> >> That's pretty heavyweight, but each function has important uses. > >This description brings a better understanding than what I had previously, but >doesn't fill in all the gaps. > >What's the purpose of a non-native error code? For that matter, if what() includes a >translated message for the error code, what purpose is there for the native error >code? For platform-specific error recovery? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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. > >> > > >> > 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 weigh in here with one strong opinion: producing localized > >> error messages should not be the job of the exception object or the > >> code which throws it. Error message formatting and localization > >> should happen after exceptions are caught. > > > >Full agreement. But what (if anything) must the exception object > >provide in order for the exception handlers to be able to format > >a localized message? > > Peter Dimov and I went back and forth about this for the filesystem library > and decided: > >... 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 locale on some O/S's. > >int native_error() const; >// a return of 0 implies a library (rather than system) error > >error_code error() const; // filesystem defined error code > >const std::string & who() const; // name of func throwing exception > >const path & path1() const; // argument 1 to func; may be empty() >const path & path2() const; // argument 2 to func; may be empty() > > That's pretty heavyweight, but each function has important uses. This description brings a better understanding than what I had previously, but doesn't fill in all the gaps. What's the purpose of a non-native error code? For that matter, if what() includes a translated message for the error code, what purpose is there for the native error code? > For Boost.Threads, path1() and path2() obviously don't apply, but I > wouldn't be surprised if a string identifying the thread in some way wasn't > a possible need. The thread will always be the current thread, so there's no need to carry that payload. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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 payload for transport to the handler? Why the code instead of the message? How do you deal with the issues I pointed out in my other posts, such as overlapping values and the need for non-OS error codes? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 might possibly support >threads-lite, but not a full Boost.Threads implementation. One solution is to just >say no. Another is to require the implementor simulate the missing features. >Implementors should make their own call on that, based on their understanding of >their market. > >There is some chance you might talk me into accepting two flavors of threading for >the Standard - full threads and threads-lite in effect. For what's it's worth, at work we have implemented complete Java thread support in our VM despite having to run in a single-threaded environment. We had to fake everything with cooroutines. But then again, I would be happy to have a simple coroutine facility in the standard, whether as a subset of the thread facility or seperately, as cooroutines are much simpler to implement and to program with. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 Boost.Threads is > to > >add priority support. It's absolutely essential for realtime > programmers, > >and they would (rightfully) reject any library that doesn't support it. > > > >Now let's imagine there's a POSIX OS that doesn't support this. You want > >to say that none of the Boost.Threads (or a C++ standard library) can be > >used on their platform, just because they don't have support for priority > > >scheduling? > > No, what I'd rather happen is that the implementation provides the priority > support. How it is implemented is the implementor's problem. >From a realtime programmers stand point, this isn't possible. If the platform >doesn't provide it there's no way for a library/compiler implementor to do this. > >And even if there's no POSIX platform like this, thinking in terms of a > C++ > >standard, what about the other platforms that aren't Windows or POSIX? > >What about embedded platforms, for instance? > > 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 might > possibly support threads-lite, but not a full Boost.Threads implementation. > One solution is to just say no. Another is to require the implementor > simulate the missing features. Implementors should make their own call on > that, based on their understanding of their market. > > 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 thread features > leaves me cold. I can understand that, but my hands are somewhat tied by POSIX, whose standards bodies took the opposite stance on this issue. > I'm reminded of the situation with I/O years ago. When standards were first > proposed for machine independent I/O, people said "we'll never use that - > it doesn't allow us to specify I/O channels, blocking factor, etc." Well, > those people are still writing assembler language I guess but who cares? > OTOH, implementors said it would be too hard to implement some of the > standard features that were required. Their customers moved on. Nowadays > everyone is happy with platforms that either do or don't support disk > drives, and no one asks for standard half-support or standard support for > special device features. I'm not 100% sure the comparison is valid, because the domains are completely different. But I appreciate and respect the view point. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
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 exception name >> > enough? If not, how do you propose a library provide >> > such a localised error message? >> >> I will weigh in here with one strong opinion: producing localized >> error messages should not be the job of the exception object or the >> code which throws it. Error message formatting and localization >> should happen after exceptions are caught. > >Full agreement. But what (if anything) must the exception object >provide in order for the exception handlers to be able to format >a localized message? Peter Dimov and I went back and forth about this for the filesystem library and decided: ... 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 locale on some O/S's. int native_error() const; // a return of 0 implies a library (rather than system) error error_code error() const; // filesystem defined error code const std::string & who() const; // name of func throwing exception const path & path1() const; // argument 1 to func; may be empty() const path & path2() const; // argument 2 to func; may be empty() That's pretty heavyweight, but each function has important uses. For Boost.Threads, path1() and path2() obviously don't apply, but I wouldn't be surprised if a string identifying the thread in some way wasn't a possible need. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 absolutely essential for realtime programmers, >and they would (rightfully) reject any library that doesn't support it. > >Now let's imagine there's a POSIX OS that doesn't support this. You want >to say that none of the Boost.Threads (or a C++ standard library) can be >used on their platform, just because they don't have support for priority >scheduling? No, what I'd rather happen is that the implementation provides the priority support. How it is implemented is the implementor's problem. >And even if there's no POSIX platform like this, thinking in terms of a C++ >standard, what about the other platforms that aren't Windows or POSIX? >What about embedded platforms, for instance? 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 might possibly support threads-lite, but not a full Boost.Threads implementation. One solution is to just say no. Another is to require the implementor simulate the missing features. Implementors should make their own call on that, based on their understanding of their market. 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 thread features leaves me cold. I'm reminded of the situation with I/O years ago. When standards were first proposed for machine independent I/O, people said "we'll never use that - it doesn't allow us to specify I/O channels, blocking factor, etc." Well, those people are still writing assembler language I guess but who cares? OTOH, implementors said it would be too hard to implement some of the standard features that were required. Their customers moved on. Nowadays everyone is happy with platforms that either do or don't support disk drives, and no one asks for standard half-support or standard support for special device features. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
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 payload for transport to the handler? There need be no necessary relationship between the exception type and/or any "portable" error code. BTW: I'd like to express one more strong preference for multiple exception types. "William E. Kempf" <[EMAIL PROTECTED]> To: Boost mailing list <[EMAIL PROTECTED]> Sent by: cc: boost-bounces@list Subject: Re: Re: [boost] Re: Next revision of boost::thread & OS error code. s.boost.org 01/10/2003 09:41 AM Please respond to Boost mailing list > Sorry, I meant what information do you have _portably_? Depends on what you mean by "portable", I guess. In some cases I'll have an error code... but like I illustrated before, I'm not convinced this is "portable". Other times there's nothing available but the reason for an error. But in the end, the question you just asked is exactly what I'm asking ;). William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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 you want to spend > > gathering information. We could provide a stack trace, > > a memory dump, a listing of running processes, the OS > > name and version, and on and on. > > Sorry, I meant what information do you have _portably_? Depends on what you mean by "portable", I guess. In some cases I'll have an error code... but like I illustrated before, I'm not convinced this is "portable". Other times there's nothing available but the reason for an error. But in the end, the question you just asked is exactly what I'm asking ;). William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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 processes, the OS name and version, and on and on. This may sound facetious, but I'm frustrated asking the same question over and over again, and think this illustrates what I've been saying all along. To restate the question one more time: "What's the minimal amount of information that would be useful and portable?" Most of the above doesn't fit that billing... and I'm not sure that an error code does either. An error code is not portable. A non-portable error code seems to be of not much use, for the following reasons: * There will be errors that occur which do not occur from calls to system services. Mapping these to system error codes is not something you can easily do in a portable fashion, and may not be possible in any event. Adding non-system specific error codes is problematic, since the values of system error codes are system specific, generally not known, and may overlap between systems. * Most people are saying they prefer different exception types over an "uber-exception" that has to be interrogated for the cause in the exception handler. I tend to agree with this. If you have seperate exceptions for each type of error that can occur then there seems to be no reason to carry an error code any way. The what() method should suffice as a portable mechanism here. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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 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 weigh in here with one strong opinion: > >> producing localized error messages should not be the > >> job of the exception object or the code which throws > >> it. Error message formatting and localization should > >> happen after exceptions are caught. > > > > Full agreement. But what (if anything) must the > > exception object provide in order for the exception > > handlers to be able to format a localized message? > > You need to decide how much information you can give them. Uhmm... that's the question I've been asking. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
> 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 library provide > > such a localised error message? > > I will weigh in here with one strong opinion: producing localized > error messages should not be the job of the exception object or the > code which throws it. Error message formatting and localization > should happen after exceptions are caught. Full agreement. But what (if anything) must the exception object provide in order for the exception handlers to be able to format a localized message? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 operating systems other than those two O/S families. > > > >Well, everything that's optional in what I proposed for Boost.Threads (so > > >far) happens to also be optional on POSIX (and by using the same > >conditional compilation scheme). > > So, don't provide Boost.Threads support for POSIX operating system flavors > which don't provide important optional POSIX features. Do any of the > important flavors of POSIX systems not provide these options? 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 absolutely essential for realtime programmers, and they would (rightfully) reject any library that doesn't support it. Now let's imagine there's a POSIX OS that doesn't support this. You want to say that none of the Boost.Threads (or a C++ standard library) can be used on their platform, just because they don't have support for priority scheduling? Does that actually make sense to you? And even if there's no POSIX platform like this, thinking in terms of a C++ standard, what about the other platforms that aren't Windows or POSIX? What about embedded platforms, for instance? > Remember, too, that you don't have to specify everything. You can leave it > up to the implementor to decide what to do on a crippled operating system. > I have a suspicion that is what the Standards committee may do with a lot > of thread related changes that we always assumed would go into the core > language execution model - don't mention the details, and just expect the > library implementor to make it all work correctly in the eyes of users. > Just as is done with the external effects of I/O operations now. I'm not sure "the implementor" would be able to do anything about some of these issues if the OS doesn't provide support... and in some cases, even if he could, it would be prohibitive for him to do so (thinking of embedded systems). > 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. I don't expect there to be compiler issues, only platform issues. And again, this is EXACTLY the case in POSIX today... yet I don't see anyone scared to use it. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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. Mainly considering that we are speaking about a library that we want to submit for a possible inclusion in the standard. Sted ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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, everything that's optional in what I proposed for Boost.Threads (so >far) happens to also be optional on POSIX (and by using the same >conditional compilation scheme). So, don't provide Boost.Threads support for POSIX operating system flavors which don't provide important optional POSIX features. Do any of the important flavors of POSIX systems not provide these options? Remember, too, that you don't have to specify everything. You can leave it up to the implementor to decide what to do on a crippled operating system. I have a suspicion that is what the Standards committee may do with a lot of thread related changes that we always assumed would go into the core language execution model - don't mention the details, and just expect the library implementor to make it all work correctly in the eyes of users. Just as is done with the external effects of I/O operations now. 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. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 more > > > exception types. I know this was suggested in the review, but don't know > > > what the plan was in regard to this. In Boost.Threads case, so far we > > have > > > need for 4 different errors: lock errors, resource errors, invalid > > arguments and > > > unsupported errors. > > > > POSIX actually distinguishes out of memory errors (ENOMEM) from other lack > > of resource errors (EAGAIN), and POSIX functions can fail with an "access > > denied" error (EPERM). > > EPERM is not an issue (I believe) for anything in Boost.Threads (yet). But won't it become relevant when you add the thread attributes? MSDN doesn't really say whether it's possible to get ERROR_ACCESS_DENIED from thread functions but I wouldn't rule out the possibility. :-) > But this doesn't really answer my basic question. Is it better to carry these > error codes in a single exception, or have multiple exception types? I believe I answered this question below. No, it is not better to lump the different errors into a single exception. Separate exceptions are fine. > (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." > > If the reason for the failure can be identified by the type of the > > exception, there should be no immediate need to carry an OS error code, > > although you should consider the "how do I translate this to a localized > > error message" problem. > > Any suggestions on that one? I haven't really seen any viable answers provided yet. The easiest is to simply return e.g. "boost::thread_resource_error" from what(), but it might prove controversial. :-) > > No, this would be a step backward. IIUC filesystem_error is expected to > > evolve into a hierarchy as exception categories of interest to callers are > > identified. > > Then why *ever* carry the OS error code. The exception type would likely > mirror every OS error code possible (with some folding, where appropriate, where > I'd expect the precise code to be irrelevant). I don't understand what the OS > error code would add. An error code (OS or portable) can be of help when one needs to catch all thread-related (or better yet, all error code providing) exceptions in a single catch clause. Usually this is only needed to report an error, though, so if thread exceptions provide some other common mechanism to identify the error (like specific what() values), carrying an error code won't be necessary. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 what POSIX > does." > > > > Why (in regards to "do what POSIX does")? They can make mistakes as > easily > > as the rest of us. > > Because they've had the time to find and correct their mistakes, I'd expect. > :-) Doesn't seem to apply, to me. If there's no reason to supply both but it had been standardized that way in the past, I'd expect they'd be loathe to change the standard, since having the seperation won't hurt. But that doesn't necessarily mean that if they had it to do over, they wouldn't simplify things by folding the error codes. > > If we do seperate them, is there any reason to provide a thread specific > memory > > exception, or should we use std::bad_alloc? > > Good question. I'll face the same problem when I finally decide to fix the > POSIX lightweight_mutex to check for error returns. :-) [As a side note, do > you plan to integrate lightweight_mutex into Boost.Threads?] Sort of. The theory was that boost::mutex should be a lightweight mutex, but that that's an implementation detail. So my plan was just to address the implementation when I had the time. > I'm not sure which piece of information is more important here, the "no > memory" part or the "this is a thread exception" part, although I'm leaning > towards a std::bad_alloc derived exception (boost::posix_enomem? > boost::thread::out_of_memory?) Naming will drive me nuts here, but I don't like using "posix" when it's not POSIX specific. > > > An error code (OS or portable) can be of help when one needs to catch > all > > > thread-related (or better yet, all error code providing) exceptions in a > > > single catch clause. Usually this is only needed to report an error, > though, > > > so if thread exceptions provide some other common mechanism to identify > the > > > error (like specific what() values), carrying an error code won't be > > > necessary. > > > > And would the above mentioned "localized message" be enough to satisfy > this > > requirement? > > I think that it would be enough for my needs. Can't speak for others. Well, I'm addressing everyone :). William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 does")? They can make mistakes as easily > as the rest of us. Because they've had the time to find and correct their mistakes, I'd expect. :-) > If we do seperate them, is there any reason to provide a thread specific memory > exception, or should we use std::bad_alloc? Good question. I'll face the same problem when I finally decide to fix the POSIX lightweight_mutex to check for error returns. :-) [As a side note, do you plan to integrate lightweight_mutex into Boost.Threads?] I'm not sure which piece of information is more important here, the "no memory" part or the "this is a thread exception" part, although I'm leaning towards a std::bad_alloc derived exception (boost::posix_enomem? boost::thread::out_of_memory?) > > An error code (OS or portable) can be of help when one needs to catch all > > thread-related (or better yet, all error code providing) exceptions in a > > single catch clause. Usually this is only needed to report an error, though, > > so if thread exceptions provide some other common mechanism to identify the > > error (like specific what() values), carrying an error code won't be > > necessary. > > And would the above mentioned "localized message" be enough to satisfy this > requirement? I think that it would be enough for my needs. Can't speak for others. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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::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 regard to this. In Boost.Threads case, so far we > > > have > > > > need for 4 different errors: lock errors, resource errors, invalid > > > arguments and > > > > unsupported errors. > > > > > > POSIX actually distinguishes out of memory errors (ENOMEM) from other > lack > > > of resource errors (EAGAIN), and POSIX functions can fail with an > "access > > > denied" error (EPERM). > > > > EPERM is not an issue (I believe) for anything in Boost.Threads (yet). > > But won't it become relevant when you add the thread attributes? Actually, yes... I missed that. In the current code I glossed over this by throwing a generic runtime_error in the one place this occurs. So... make that currently 5 exception types needed (with a possible 6th if you want to distinguish memory and other resources). > MSDN doesn't really say whether it's possible to get ERROR_ACCESS_DENIED > from thread functions but I wouldn't rule out the possibility. :-) They don't say it directly... but it's heavily implied. I'd be floored if that were not a possibility. (In case you don't get the implication... it comes from CreateThread taking a security attribute.) > > But this doesn't really answer my basic question. Is it better to carry > these > > error codes in a single exception, or have multiple exception types? > > I believe I answered this question below. No, it is not better to lump the > different errors into a single exception. Separate exceptions are fine. Yes, you answered below. Sorry... I usually reply as I read as a bad habit. > > (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 does")? They can make mistakes as easily as the rest of us. If we do seperate them, is there any reason to provide a thread specific memory exception, or should we use std::bad_alloc? > > > If the reason for the failure can be identified by the type of the > > > exception, there should be no immediate need to carry an OS error code, > > > although you should consider the "how do I translate this to a localized > > > error message" problem. > > > > Any suggestions on that one? I haven't really seen any viable answers > provided yet. > > The easiest is to simply return e.g. "boost::thread_resource_error" from > what(), but it might prove controversial. :-) Not to me ;). > > > No, this would be a step backward. IIUC filesystem_error is expected to > > > evolve into a hierarchy as exception categories of interest to callers > are > > > identified. > > > > Then why *ever* carry the OS error code. The exception type would likely > > mirror every OS error code possible (with some folding, where appropriate, > where > > I'd expect the precise code to be irrelevant). I don't understand what > the OS > > error code would add. > > An error code (OS or portable) can be of help when one needs to catch all > thread-related (or better yet, all error code providing) exceptions in a > single catch clause. Usually this is only needed to report an error, though, > so if thread exceptions provide some other common mechanism to identify the > error (like specific what() values), carrying an error code won't be > necessary. And would the above mentioned "localized message" be enough to satisfy this requirement? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 the review, but don't know > > what the plan was in regard to this. In Boost.Threads case, so far we > have > > need for 4 different errors: lock errors, resource errors, invalid > arguments and > > unsupported errors. > > POSIX actually distinguishes out of memory errors (ENOMEM) from other lack > of resource errors (EAGAIN), and POSIX functions can fail with an "access > denied" error (EPERM). EPERM is not an issue (I believe) for anything in Boost.Threads (yet). But this doesn't really answer my basic question. Is it better to carry these error codes in a single exception, or have multiple exception types? (And is it useful to distinguish between memory and other resource errors?) > There are also several types of POSIX lock errors (EINVAL, EBUSY, EAGAIN, > EDEADLK, EPERM.) Boost.Threads has two additional lock errors associated > with the Lock concept that have no POSIX equivalent. Yep. > > Some have suggested carrying the OS error code, but given only 4 possible > error > > conditions, does this even sound reasonable? > > If the reason for the failure can be identified by the type of the > exception, there should be no immediate need to carry an OS error code, > although you should consider the "how do I translate this to a localized > error message" problem. Any suggestions on that one? I haven't really seen any viable answers provided yet. > > Or are people > > suggesting Boost.Threads should use a single exception type and carry the > error > > code, as filesystem_error currently does? > > No, this would be a step backward. IIUC filesystem_error is expected to > evolve into a hierarchy as exception categories of interest to callers are > identified. Then why *ever* carry the OS error code. The exception type would likely mirror every OS error code possible (with some folding, where appropriate, where I'd expect the precise code to be irrelevant). I don't understand what the OS error code would add. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 regard to this. In Boost.Threads case, so far we have > need for 4 different errors: lock errors, resource errors, invalid arguments and > unsupported errors. POSIX actually distinguishes out of memory errors (ENOMEM) from other lack of resource errors (EAGAIN), and POSIX functions can fail with an "access denied" error (EPERM). There are also several types of POSIX lock errors (EINVAL, EBUSY, EAGAIN, EDEADLK, EPERM.) Boost.Threads has two additional lock errors associated with the Lock concept that have no POSIX equivalent. > Some have suggested carrying the OS error code, but given only 4 possible error > conditions, does this even sound reasonable? If the reason for the failure can be identified by the type of the exception, there should be no immediate need to carry an OS error code, although you should consider the "how do I translate this to a localized error message" problem. > Or are people > suggesting Boost.Threads should use a single exception type and carry the error > code, as filesystem_error currently does? No, this would be a step backward. IIUC filesystem_error is expected to evolve into a hierarchy as exception categories of interest to callers are identified. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 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 information. >> > > > >> > > > Agreed. And we should keep coherence with the filesystem library. >> > > >> > > I'm not sure there's any coherence to keep here. Do you have specific >> > concerns/thoughts here? >> > >> > I was thinking about keeping similar design patterns between these two >> > libraries. >> > (because they are conceptually similar as they both give a portable view of >> > operating system functionalities). >> > So if we use domain specific exception in the filesystem library, the thread >> > library should follow the same pattern too. The same for the issue of >> > conditional compilation. >> >> I'll look at this closer, but the domains are different enough that I'm not sure >there's anything that carries over. > >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 >regard to this. In Boost.Threads case, so far we have need for 4 different errors: >lock errors, resource errors, invalid arguments and unsupported errors. Some have >suggested carrying the OS error code, but given only 4 possible error conditions, >does this even sound reasonable? Or are people suggesting Boost.Threads should use a >single exception type and carry the error code, as filesystem_error currently does? I think it depends on how useful the four different types and the OS error code are for recovery purposes. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 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. > > > > > > > > Agreed. And we should keep coherence with the filesystem library. > > > > > > I'm not sure there's any coherence to keep here. Do you have specific > > concerns/thoughts here? > > > > I was thinking about keeping similar design patterns between these two > > libraries. > > (because they are conceptually similar as they both give a portable view of > > operating system functionalities). > > So if we use domain specific exception in the filesystem library, the thread > > library should follow the same pattern too. The same for the issue of > > conditional compilation. > > I'll look at this closer, but the domains are different enough that I'm not sure >there's anything that carries over. 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 regard to this. In Boost.Threads case, so far we have need for 4 different errors: lock errors, resource errors, invalid arguments and unsupported errors. Some have suggested carrying the OS error code, but given only 4 possible error conditions, does this even sound reasonable? Or are people suggesting Boost.Threads should use a single exception type and carry the error code, as filesystem_error currently does? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 compilation is > that a design decision was made to limit the library to features which > could be implemented in both POSIX and Windows. > > Otherwise it would have been shot full of optional/conditional features. > > 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, everything that's optional in what I proposed for Boost.Threads (so far) happens to also be optional on POSIX (and by using the same conditional compilation scheme). That's precisely why I said "As for conditional compilation... the Boost.Filesystem stuff has no need for this, while Boost.Threads has a very definate need." The features left to be provided by Boost.Threads (other than barriers, thread pools and read/write mutexes), and that most of it's users are requesting, happen to fall into this "optional" category in POSIX. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 library to features which could be implemented in both POSIX and Windows. Otherwise it would have been shot full of optional/conditional features. 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. What I found doing research for the Filesystem library was that most of the remaining legacy systems have been retrofitted to support POSIX, while new O/S designs tend to support POSIX right from the start. What is left are features that are so system specific that those wishing to take advantage of the features should just use the operating system's native API. The programs aren't going to be portable in any case, so why provide an illusion of portability where there is none? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 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. > > > > > > Agreed. And we should keep coherence with the filesystem library. > > > > I'm not sure there's any coherence to keep here. Do you have specific > concerns/thoughts here? > > I was thinking about keeping similar design patterns between these two > libraries. > (because they are conceptually similar as they both give a portable view of > operating system functionalities). > So if we use domain specific exception in the filesystem library, the thread > library should follow the same pattern too. The same for the issue of > conditional compilation. I'll look at this closer, but the domains are different enough that I'm not sure there's anything that carries over. As for conditional compilation... the Boost.Filesystem stuff has no need for this, while Boost.Threads has a very definate need. > BTW I prefer having the same set of methods, some of them returning default > values for platform without the support for the underline concept. > Sometimes this could not be possible. ACE for instance uses a different > approach. Again, dummy stubs won't work in all cases. A better example than I've already given is the attribute to make a mutex visible across process boundaries. Not all platforms will support this, and if they don't a stub that returns an error or throws an exception is doing a great disservice to the developer, since he should know at compile time that this platform can't handle this, since there's nothing he can do at run time to compensate for the lack. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 the extra information, on POSIX it would be a good idea to provide > the errno-compatible error code returned by pthread_*, and it _might_ be a > good idea to supply a portable error code, too, as the filesystem library > does. > Fully agreed. That is an example of what I meant with "coherence between the two libraries". Sted ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 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. > > > > > > What extra information do you want provided? > > > > For example, that it was a threading library exception. Information > > carried by the type identity may be enough. > > It's the "may" that concerns me here. I have absolutely no problem using a > domain specific exception type here... I just want to insure doing so covers _all_ > the needs. 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 the extra information, on POSIX it would be a good idea to provide the errno-compatible error code returned by pthread_*, and it _might_ be a good idea to supply a portable error code, too, as the filesystem library does. When I suggested that we adopt values as the portable error code, I had the following in mind. It would be possible to catch thread and filesystem exceptions with a single catch clause if they share the same error code function... although I'm not yet sure whether this is necessary. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
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 use the std:: exceptions? > > > > > > IMO, it's always safer to use an exception type which provides > > > more-specific information. > > > > Agreed. And we should keep coherence with the filesystem library. > > I'm not sure there's any coherence to keep here. Do you have specific concerns/thoughts here? I was thinking about keeping similar design patterns between these two libraries. (because they are conceptually similar as they both give a portable view of operating system functionalities). So if we use domain specific exception in the filesystem library, the thread library should follow the same pattern too. The same for the issue of conditional compilation. BTW I prefer having the same set of methods, some of them returning default values for platform without the support for the underline concept. Sometimes this could not be possible. ACE for instance uses a different approach. Sted ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 std:: exceptions? > >> > >> IMO, it's always safer to use an exception type which provides > >> more-specific information. > > > > What extra information do you want provided? > > For example, that it was a threading library exception. Information > carried by the type identity may be enough. It's the "may" that concerns me here. I have absolutely no problem using a domain specific exception type here... I just want to insure doing so covers _all_ the needs. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 safer to use an exception type which provides > > more-specific information. > > Agreed. And we should keep coherence with the filesystem library. I'm not sure there's any coherence to keep here. Do you have specific concerns/thoughts here? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
> 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 information. What extra information do you want provided? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
