Topic: C++ standard exception classes and error strings
Author: "Edward Diener" <eldiener@earthlink.net>
Date: Mon, 1 Apr 2002 21:39:30 GMT Raw View
"Peter Dimov" <pdimov@mmltd.net> wrote in message
news:7dc3b1ea.0203300441.1f955bb5@posting.google.com...
> Edward Diener <eldiener@earthlink.net> wrote in message
news:<3CA472AF.8010903@earthlink.net>...
> > Peter Dimov wrote:
> >
> [...]
> > Let's suppose the standard exceptions were parameterized on character
> > type. Then as a simple example:
> >
> > template <typename charT> CharTypeClass
> > {
> >
> > void SomeTemplateFunction ( // Some parameters )
> > {
> > try { // do something using a class parameterized on character type }
> > catch ( std::exception<charT> & ex ) { // handle exception }
> > }
> >
> > };
> >
> > My general argument for parameterized exception classes is that it gives
> > the facility for throwing and handling wide character exceptions, and
> > thus returning wide character error strings from the exception. This
> > doesn't mean it needs to be done often, but for modules which feel the
> > need to report wide character errors, the standard exception classes
> > could then be used.
>
> Thanks, I now understand your argument better. I'm still not sure I
> buy it in its entirety since I don't see why a class parameterized on
> charT should necessarily throw an exception parameterized on the same
> character type. Why should there be an 1:1 correspondence between the
> two? Should every std::wstring operation throw std::wexception? Why?
Because the error string of the exception might need to be related to the
character type. After all using a wide character parameterized class
normally assumes that the end user of the class is implementing its
functionality for a language which supports wide character literals and not
narrow character literals.
In my scenario, I would not normally expect class templates parameterized on
"char"
to throw a wide character exception and vice versa ?
> The problem with several separate exception hierarchies is that code
> needs to have separate catch handlers for std::exception,
> std::wexception, and potentially for other character types; I don't
> see what is gained by this.
It depends on what is being thrown. If one is interested in supporting wide
character versions of some class template, I think that one should be
willing to
catch possible wide character string exceptions
> > > Which means that every low-level function should somehow know about
> > > the operating system in order to determine the appropriate character
> > > type.
> >
> >
> > Your pushing your reasonable arguments to absurdity. 99% of everybody
> > would still use the exception hierarchy parameterized on "char". I'm not
> > mandating some strict regulation, just suggesting a flexible alternative
> > to support better localization in C++.
>
> Yes, this is exactly my point, that a std::wexception _does not_
> support better localization. You are necessarily limited to a single
> language (and a single message in general, i.e. you can't change its
> format) per exception.
It supports better localization purely in the sense that a wide character
implementation of anything can now throw an exception with an error string
for a language which is a wide character language. Perhaps one really does
know the language, say Japanese, and wants to pass back an error string that
a Japanese user would understand. Must it be up to the user of the class to
know Japanese instead ? After all why shouldn't a good implementor who knows
foreign languages be allowed to support one in his code from within the
exception hierarchy.
> Typically, in localization-aware code the higher level layer (the
> catch point) needs to control the message format, appearance, and
> language. The low level layer (the throw point) doesn't have the
> necessary information for this.
I agree with this as the most typical case but that doesn't make it the
only case.
> To get a bit more concrete, there are three practical alternatives for
> localization-aware code:
>
> [1] The throw point somehow obtains the necessary information to
> format the message (via function arguments, global variables, or
> global 'callback' functions supplied by the high level layer) and
> stores a wstring in the exception.
>
> [2] The throw point stores all relevant information in the exception,
> the catch point formats the message as appropriate (or doesn't create
> a message at all if this isn't necessary.)
>
> [3] The throw point stores all relevant information in the exception;
> the catch point calls a what() method passing the formatting
> instructions, the exception class formats the message.
>
> You are arguing for [1]. I think that both [2] and [3] are better
> approaches to localization - [1] has extra dependencies, the low level
> code is less project-independent, and you can't change the message
> once the exception is thrown.
3) is like 1) also. The exception class may want to return a wide character
result also from the what() method if the exception is for use in a wide
character environment. In 2), which I agree is traditionally the typical
case, the handler will pick up the error string as a code, read the
documentation about what the code means, and translate it accordingly.
> > > When a message store exists, one can throw exceptions that contain the
> > > identifier of the message, as I explained.
> >
> >
> > Suppose I want something a little more rich than a std::string
> > identifier such as an actual error message.
>
> On the contrary, the actual error message is "less rich" than an
> identifier. You can no longer reformat it or change its language.
>
> > Your solution is to mandate that exceptions return ASCII identifiers.
>
> Not at all. I don't intend to mandate anything. I'm simply trying to
> point out that throwing a std::wexception is not the best approach to
> localization.
>
> > I
> > don't regard this as solving the problem since I think of such a
> > solution as being way too restrictive.
>
> Oh well, it works for me, in situations where a std::wexception
> wouldn't. I regard it as more flexible.
I don't see how an exception
hierarchy which returns just a std::string error is richer and more flexible
than one which also allows a std::wstring to be returned.
I can understand your argument that you don't think it is worth the extra
effort to
support this parameterized hierarchy over what already exists based on the
purpose which I have suggested, which is to support wide string error
messages.
However, let
me add one more argument for my position. Let's assume that C++ might
sometime in the future support more native character types other than "char"
and "wchar_t", something like a commonly adopted Unicode as a "unichar". Now
we have this same exception hierarchy still throwing exceptions with an
error string which is a string of "char"s. At what point does someone say
that C++'s exception hierarchy should support other error string types, or
are we forever to say that all exception strings should be ASCII and then
its up to the handler to translate this accordingly ? This latter is a
viable
interpretation but I wonder if it was the intention of the original
implementor(s) of the std::exception class hierarchy. My guess is that while
the error string could of course return anything such as an internal error
code, the original thought was that it probably would return a
human-readable string.
..
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Christopher Eltschka <celtschk@web.de>
Date: Tue, 2 Apr 2002 22:08:40 GMT Raw View
"Edward Diener" <eldiener@earthlink.net> writes:
> "Peter Dimov" <pdimov@mmltd.net> wrote in message
> news:7dc3b1ea.0203300441.1f955bb5@posting.google.com...
> > Edward Diener <eldiener@earthlink.net> wrote in message
> news:<3CA472AF.8010903@earthlink.net>...
> > > Peter Dimov wrote:
> > >
> > [...]
> > > Let's suppose the standard exceptions were parameterized on character
> > > type. Then as a simple example:
> > >
> > > template <typename charT> CharTypeClass
> > > {
> > >
> > > void SomeTemplateFunction ( // Some parameters )
> > > {
> > > try { // do something using a class parameterized on character type }
> > > catch ( std::exception<charT> & ex ) { // handle exception }
> > > }
> > >
> > > };
> > >
> > > My general argument for parameterized exception classes is that it gives
> > > the facility for throwing and handling wide character exceptions, and
> > > thus returning wide character error strings from the exception. This
> > > doesn't mean it needs to be done often, but for modules which feel the
> > > need to report wide character errors, the standard exception classes
> > > could then be used.
> >
> > Thanks, I now understand your argument better. I'm still not sure I
> > buy it in its entirety since I don't see why a class parameterized on
> > charT should necessarily throw an exception parameterized on the same
> > character type. Why should there be an 1:1 correspondence between the
> > two? Should every std::wstring operation throw std::wexception? Why?
>
> Because the error string of the exception might need to be related to the
> character type. After all using a wide character parameterized class
> normally assumes that the end user of the class is implementing its
> functionality for a language which supports wide character literals and not
> narrow character literals.
Now assume that the class calls new to allocate memory. Now new may
throw a bad_alloc. Or should it throw a wbad_alloc? Or should it throw
a wbad_alloc if it's allocating wchar_t, and bad_alloc otherwise? Or
always wbad_alloc, unless allocating char?
And would your code then look like
try
{
// some code using both wchar_t related classes and classes not
// related to any character type
}
catch(bad_alloc& ex)
{
// handling of allocation error
}
catch(wbad_alloc& ex)
{
// exactly the same code again, in case the allocation error
// happened in the whar_t related classes
}
[...]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: "Edward Diener" <eldiener@earthlink.net>
Date: Wed, 3 Apr 2002 00:45:16 GMT Raw View
"Christopher Eltschka" <celtschk@web.de> wrote in message
news:a8cn8p$7bd$1@news.tuwien.ac.at...
> "Edward Diener" <eldiener@earthlink.net> writes:
>
> > "Peter Dimov" <pdimov@mmltd.net> wrote in message
> > news:7dc3b1ea.0203300441.1f955bb5@posting.google.com...
> > > Edward Diener <eldiener@earthlink.net> wrote in message
> > news:<3CA472AF.8010903@earthlink.net>...
> > > > Peter Dimov wrote:
> > > >
> > > [...]
> > > > Let's suppose the standard exceptions were parameterized on
character
> > > > type. Then as a simple example:
> > > >
> > > > template <typename charT> CharTypeClass
> > > > {
> > > >
> > > > void SomeTemplateFunction ( // Some parameters )
> > > > {
> > > > try { // do something using a class parameterized on character
type }
> > > > catch ( std::exception<charT> & ex ) { // handle exception }
> > > > }
> > > >
> > > > };
> > > >
> > > > My general argument for parameterized exception classes is that it
gives
> > > > the facility for throwing and handling wide character exceptions,
and
> > > > thus returning wide character error strings from the exception. This
> > > > doesn't mean it needs to be done often, but for modules which feel
the
> > > > need to report wide character errors, the standard exception classes
> > > > could then be used.
> > >
> > > Thanks, I now understand your argument better. I'm still not sure I
> > > buy it in its entirety since I don't see why a class parameterized on
> > > charT should necessarily throw an exception parameterized on the same
> > > character type. Why should there be an 1:1 correspondence between the
> > > two? Should every std::wstring operation throw std::wexception? Why?
> >
> > Because the error string of the exception might need to be related to
the
> > character type. After all using a wide character parameterized class
> > normally assumes that the end user of the class is implementing its
> > functionality for a language which supports wide character literals and
not
> > narrow character literals.
>
> Now assume that the class calls new to allocate memory. Now new may
> throw a bad_alloc. Or should it throw a wbad_alloc? Or should it throw
> a wbad_alloc if it's allocating wchar_t, and bad_alloc otherwise? Or
> always wbad_alloc, unless allocating char?
>
> And would your code then look like
>
> try
> {
> // some code using both wchar_t related classes and classes not
> // related to any character type
> }
> catch(bad_alloc& ex)
> {
> // handling of allocation error
> }
> catch(wbad_alloc& ex)
> {
> // exactly the same code again, in case the allocation error
> // happened in the whar_t related classes
> }
I understand your point and it is a good one. As the saying goes in
Americanese, I hadn't thought of that.
One could add into the language a "new<charT> someType" to allow "new" to
throw wbad_alloc on allocation failure if "new<wchar_t> someType" was used.
The current "new someType" would default to "new<char> someType" and it
would therefore be transparent to current code. Using one or the other
should be the choice of the function doing the "new<charT> someType" and of
course should be documented. The same above for placement "new".
As for catching, if one were not at the "new<charT>" point but further up in
the catch hierarchy, of course one would have to catch both if there was any
question of both a bad_alloc and wbad_alloc being thrown. Even if one were
at the "new" point, the object could internally be doing a different type of
"new<charT> someType" and so both types would have to be caught. Yes, a
pain, but multiple catches are fairly common in C++ and very much a part of
the language.
I think in reality, one of these scenarios often occurs:
1) The object doing the "new" directly has an immediate catch for bad_alloc
and then of course knows what type of bad_alloc to try to catch based on the
"new<charT> someType" being done.
2) The hierarchy of "new<charT> someType" for internal "new"ing is all the
same, either wide character or Ascii character so the possible catch is
known.
In either case a single bad_alloc<charT> would be caught.
Yes, of course it's possible to catch a bad_alloc that is deep within the
code and not know which one has been thrown, and then be forced to catch
both. But there is such a thing as documentation.
Disregarding my new<charT> suggestion, as a final practical possibility,
which I really don't like all that much, bad_alloc is always thrown and
never wbad_alloc even though both exist because of the templated standard
exception hierarchy I propose. Who really cares about the error string when
bad_alloc is thrown anyway, since it is implementation defined and the
implementation is doing the throwing anyway. I haven't used a compiler yet
that documents the possible error strings returned from bad_alloc. I am
aware that knowing the reason for an allocation failure might be valuable
but in practical reality it probably isn't often used.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: pdimov@mmltd.net (Peter Dimov)
Date: Fri, 29 Mar 2002 10:49:34 GMT Raw View
Edward Diener <eldiener@earthlink.net> wrote in message news:<3CA1E8B7.3050107@earthlink.net>...
> Peter Dimov wrote:
>
> > Typically, the low level
> > function that throws the exception doesn't know the language on which
> > the user should receive the message;
>
>
> The function doesn't have to know the language, but whether the class
> throwing the exception is parameterized on char or wchar_t.
It is the low-level function that throws the exception, not a class.
Let's use std::vector::at as an example. How would it determine
whether to throw a wexception, and if so, what would the wstring
store?
How would the client catch the exception? You can't write templatized
catch handlers.
> Hardcoded
> strings could always be widened for wide character environments. Of
> course if no such parameterization occurs, which is often the case, then
> it would the choice of the class implementor which to use, but if
> exceptions were parameterized on character type, then naturally throwing
> an exception would use the same character type so any error strings
> would match that type.
>
> In many operating systems, the class implementor could determine whether
> narrow or wide character messages were appropriate at run-time from
> localization settings.
Which means that every low-level function should somehow know about
the operating system in order to determine the appropriate character
type.
> I am not sure but perhaps the std::locale also
> has this information.
Which std::locale? You can have an unlimited number of them in a
program.
> This would also allow countries whose language could only be expressed
> internally in wide characters to supply their own wide character error
> strings as a resource ( Posix message catalog or Windows resource DLL )
> and the particular parameterized class could then throw a standard
> exception using such understandable messages without having to know its
> meaning in that other language.
When a message store exists, one can throw exceptions that contain the
identifier of the message, as I explained.
> > therefore, the exception should
> > usually store the identifier of the message, not its text.
> > std::strings make good identifiers.
>
>
> What an exception should usually do in your opinion doesn't negate the
> need to allow exceptions to be parameterized so that wide character
> error strings can be returned, but I understand your practical
> suggestion. But unfortunately in the real programming world, and even in
> Boost, this is not always the case, nor is it always practical.
IOW my opinion (and the fact that it solves the problem) is irrelevant
while yours is. Could you please at least provide a concrete example
taken from the real programming world, or from Boost, where you need
to parameterize the exception classes on a character type?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Edward Diener <eldiener@earthlink.net>
Date: Fri, 29 Mar 2002 16:11:01 GMT Raw View
Peter Dimov wrote:
> Edward Diener <eldiener@earthlink.net> wrote in message news:<3CA1E8B7.3050107@earthlink.net>...
>
>>Peter Dimov wrote:
>>
>>
>>>Typically, the low level
>>>function that throws the exception doesn't know the language on which
>>>the user should receive the message;
>>>
>>
>>The function doesn't have to know the language, but whether the class
>>throwing the exception is parameterized on char or wchar_t.
>>
>
> It is the low-level function that throws the exception, not a class.
Touche !
> Let's use std::vector::at as an example. How would it determine
> whether to throw a wexception, and if so, what would the wstring
> store?
I don't say that every class would need to invesigate whether to throw a
wide character exception, but that the facility would exist for class
templates parameterized on the character type to throw exceptions whose
error string was parameterized on the same character type, as well as
for programmers to choose if they wish.
>
> How would the client catch the exception? You can't write templatized
> catch handlers.
>
You can catch exceptions for any class type and the wide character
exceptions are just another hierarchy of class types.
It would be documented if the thrower was throwing a wide character
exception from a wide character class template. Furthermore if an
exception were being caught from within a class template member function
parameterized on character type, the function could automatically be
written so that the correct catch handler is generated if using a class
which throws such a parameterized exception.
Let's suppose the standard exceptions were parameterized on character
type. Then as a simple example:
template <typename charT> CharTypeClass
{
void SomeTemplateFunction ( // Some parameters )
{
try { // do something using a class parameterized on character type }
catch ( std::exception<charT> & ex ) { // handle exception }
}
};
My general argument for parameterized exception classes is that it gives
the facility for throwing and handling wide character exceptions, and
thus returning wide character error strings from the exception. This
doesn't mean it needs to be done often, but for modules which feel the
need to report wide character errors, the standard exception classes
could then be used.
>
>>Hardcoded
>>strings could always be widened for wide character environments. Of
>>course if no such parameterization occurs, which is often the case, then
>>it would the choice of the class implementor which to use, but if
>>exceptions were parameterized on character type, then naturally throwing
>>an exception would use the same character type so any error strings
>>would match that type.
>>
>>In many operating systems, the class implementor could determine whether
>>narrow or wide character messages were appropriate at run-time from
>>localization settings.
>>
>
> Which means that every low-level function should somehow know about
> the operating system in order to determine the appropriate character
> type.
Your pushing your reasonable arguments to absurdity. 99% of everybody
would still use the exception hierarchy parameterized on "char". I'm not
mandating some strict regulation, just suggesting a flexible alternative
to support better localization in C++.
I can be absurd also and suggest that C++ get rid of std::wstring
because programmers somehow have to choose between std::string and
std::wstring in the usual situations.
>
>
>>I am not sure but perhaps the std::locale also
>>has this information.
>>
>
> Which std::locale? You can have an unlimited number of them in a
> program.
>
std::locale as a class with its facets. I don't know whether a
particular std::locale has a facet which tells whether or not that
locale supports a wide character set or a narrow character set as its
default.
>
>>This would also allow countries whose language could only be expressed
>>internally in wide characters to supply their own wide character error
>>strings as a resource ( Posix message catalog or Windows resource DLL )
>>and the particular parameterized class could then throw a standard
>>exception using such understandable messages without having to know its
>>meaning in that other language.
>>
>
> When a message store exists, one can throw exceptions that contain the
> identifier of the message, as I explained.
Suppose I want something a little more rich than a std::string
identifier such as an actual error message.
>
>
>>>therefore, the exception should
>>>usually store the identifier of the message, not its text.
>>>std::strings make good identifiers.
>>>
>>
>>What an exception should usually do in your opinion doesn't negate the
>>need to allow exceptions to be parameterized so that wide character
>>error strings can be returned, but I understand your practical
>>suggestion. But unfortunately in the real programming world, and even in
>>Boost, this is not always the case, nor is it always practical.
>>
>
> IOW my opinion (and the fact that it solves the problem) is irrelevant
> while yours is.
Your solution is to mandate that exceptions return ASCII identifiers. I
don't regard this as solving the problem since I think of such a
solution as being way too restrictive.
> Could you please at least provide a concrete example
> taken from the real programming world, or from Boost, where you need
> to parameterize the exception classes on a character type?
In the Regex++ library, Dr. Maddock has his traits classes returning all
error strings from exceptions as narrow strings. These are not
identifers but actual messages. In order to allow the user of the
library to configure these messages for localization, he allows message
catalogs or Windows resource DLLs to be used. This will not work well
for wide character languages where ideographs can be represented best as
wide characters. Yes, I am aware of multi-byte encoding in some wide
character languages.
The concrete example really interests me much less than the ideal.
For me the exception classes should be parameterized on character type because a key
ingredient of them is the error string. Saying that the solution is to
limit the error string to an identifier does not appear to me to be a
viable solution. Parameterizing the exception class hierarchy on
character type supports wide character error strings without any change
in logic and looks toward the future where other native character types
may be added to the C++ language.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: pdimov@mmltd.net (Peter Dimov)
Date: Sun, 31 Mar 2002 00:37:16 GMT Raw View
Edward Diener <eldiener@earthlink.net> wrote in message news:<3CA472AF.8010903@earthlink.net>...
> Peter Dimov wrote:
>
[...]
> Let's suppose the standard exceptions were parameterized on character
> type. Then as a simple example:
>
> template <typename charT> CharTypeClass
> {
>
> void SomeTemplateFunction ( // Some parameters )
> {
> try { // do something using a class parameterized on character type }
> catch ( std::exception<charT> & ex ) { // handle exception }
> }
>
> };
>
> My general argument for parameterized exception classes is that it gives
> the facility for throwing and handling wide character exceptions, and
> thus returning wide character error strings from the exception. This
> doesn't mean it needs to be done often, but for modules which feel the
> need to report wide character errors, the standard exception classes
> could then be used.
Thanks, I now understand your argument better. I'm still not sure I
buy it in its entirety since I don't see why a class parameterized on
charT should necessarily throw an exception parameterized on the same
character type. Why should there be an 1:1 correspondence between the
two? Should every std::wstring operation throw std::wexception? Why?
The problem with several separate exception hierarchies is that code
needs to have separate catch handlers for std::exception,
std::wexception, and potentially for other character types; I don't
see what is gained by this.
> > Which means that every low-level function should somehow know about
> > the operating system in order to determine the appropriate character
> > type.
>
>
> Your pushing your reasonable arguments to absurdity. 99% of everybody
> would still use the exception hierarchy parameterized on "char". I'm not
> mandating some strict regulation, just suggesting a flexible alternative
> to support better localization in C++.
Yes, this is exactly my point, that a std::wexception _does not_
support better localization. You are necessarily limited to a single
language (and a single message in general, i.e. you can't change its
format) per exception.
Typically, in localization-aware code the higher level layer (the
catch point) needs to control the message format, appearance, and
language. The low level layer (the throw point) doesn't have the
necessary information for this.
To get a bit more concrete, there are three practical alternatives for
localization-aware code:
[1] The throw point somehow obtains the necessary information to
format the message (via function arguments, global variables, or
global 'callback' functions supplied by the high level layer) and
stores a wstring in the exception.
[2] The throw point stores all relevant information in the exception,
the catch point formats the message as appropriate (or doesn't create
a message at all if this isn't necessary.)
[3] The throw point stores all relevant information in the exception;
the catch point calls a what() method passing the formatting
instructions, the exception class formats the message.
You are arguing for [1]. I think that both [2] and [3] are better
approaches to localization - [1] has extra dependencies, the low level
code is less project-independent, and you can't change the message
once the exception is thrown.
> > When a message store exists, one can throw exceptions that contain the
> > identifier of the message, as I explained.
>
>
> Suppose I want something a little more rich than a std::string
> identifier such as an actual error message.
On the contrary, the actual error message is "less rich" than an
identifier. You can no longer reformat it or change its language.
> Your solution is to mandate that exceptions return ASCII identifiers.
Not at all. I don't intend to mandate anything. I'm simply trying to
point out that throwing a std::wexception is not the best approach to
localization.
> I
> don't regard this as solving the problem since I think of such a
> solution as being way too restrictive.
Oh well, it works for me, in situations where a std::wexception
wouldn't. I regard it as more flexible.
> > Could you please at least provide a concrete example
> > taken from the real programming world, or from Boost, where you need
> > to parameterize the exception classes on a character type?
>
>
> In the Regex++ library, Dr. Maddock has his traits classes returning all
> error strings from exceptions as narrow strings. These are not
> identifers but actual messages. In order to allow the user of the
> library to configure these messages for localization, he allows message
> catalogs or Windows resource DLLs to be used. This will not work well
> for wide character languages where ideographs can be represented best as
> wide characters. Yes, I am aware of multi-byte encoding in some wide
> character languages.
>
> The concrete example really interests me much less than the ideal.
Yes, a good example.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: pdimov@mmltd.net (Peter Dimov)
Date: Wed, 27 Mar 2002 13:31:42 GMT Raw View
Edward Diener <eldiener@earthlink.net> wrote in message news:<3C9E8CF0.5000403@earthlink.net>...
> Nearly all of the C++ standard exception classes report their errors as
> std::string s. Why were they not paramaterized on the character type so
> that the errors could be reported as wstring s for wide character
> environments ?
FWIW, I have never needed to throw wstrings. Typically, the low level
function that throws the exception doesn't know the language on which
the user should receive the message; therefore, the exception should
usually store the identifier of the message, not its text.
std::strings make good identifiers.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Edward Diener <eldiener@earthlink.net>
Date: Wed, 27 Mar 2002 18:22:41 GMT Raw View
Peter Dimov wrote:
> Edward Diener <eldiener@earthlink.net> wrote in message news:<3C9E8CF0.5000403@earthlink.net>...
>
>>Nearly all of the C++ standard exception classes report their errors as
>>std::string s. Why were they not paramaterized on the character type so
>>that the errors could be reported as wstring s for wide character
>>environments ?
>>
>
> FWIW, I have never needed to throw wstrings.
One throws exceptions, not strings <g>.
> Typically, the low level
> function that throws the exception doesn't know the language on which
> the user should receive the message;
The function doesn't have to know the language, but whether the class
throwing the exception is parameterized on char or wchar_t. Hardcoded
strings could always be widened for wide character environments. Of
course if no such parameterization occurs, which is often the case, then
it would the choice of the class implementor which to use, but if
exceptions were parameterized on character type, then naturally throwing
an exception would use the same character type so any error strings
would match that type.
In many operating systems, the class implementor could determine whether
narrow or wide character messages were appropriate at run-time from
localization settings. I am not sure but perhaps the std::locale also
has this information.
This would also allow countries whose language could only be expressed
internally in wide characters to supply their own wide character error
strings as a resource ( Posix message catalog or Windows resource DLL )
and the particular parameterized class could then throw a standard
exception using such understandable messages without having to know its
meaning in that other language.
> therefore, the exception should
> usually store the identifier of the message, not its text.
> std::strings make good identifiers.
What an exception should usually do in your opinion doesn't negate the
need to allow exceptions to be parameterized so that wide character
error strings can be returned, but I understand your practical
suggestion. But unfortunately in the real programming world, and even in
Boost, this is not always the case, nor is it always practical.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Edward Diener <eldiener@earthlink.net>
Date: Mon, 25 Mar 2002 21:03:41 GMT Raw View
Nearly all of the C++ standard exception classes report their errors as
std::string s. Why were they not paramaterized on the character type so
that the errors could be reported as wstring s for wide character
environments ?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]