Hello

Can a new method std::exception::wcs_what() (or alike) be added to the
standard library base exception class ?

I find the current approach, that the what() string can be converted to a
wstring for display, leaves the problem of transporting wide-character error
messages open, because:

       - in most locales the narrow-character set is much smaller than
         the wide-character set. So with a narrow string you can not
         really transport wide characters.

       - using a different charset than the one in the current locale,
         like UTF-8, for the what() string, would require all libraries
         (and catch sites) used in the program to know about and follow
         such a convention, or otherwise would require that all catch
         sites know about and detect specific instances of
         std::exception that have the what() string encoded differently

I think the ability to construct a runtime_error with a wchar_t * argument,
and a wcs_what() method in std::exception, would be a global solution for
wide-character error messages (meaning different libraries/modules need not
follow a convention for what() strings and need not be changed).

Also, a member function template in std::exception, like

template<typename charT>
  charT const *message_string();

with a requirement to be specialized only for types char and wchar_t, would
be nice as the catch site could do:


...
}
catch (std::exception const &ex)
{
  basic_string<TCHAR> strError(ex.message_string<TCHAR>());

  // log/output the string...
  // ...
}
catch (...)
{
  basic_string<TCHAR> strError(_T("Application error"));

  // ...
}

and then the application could be written to always use wchar_t, or to
always use char, depending on the definition of TCHAR.

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jul 21, 7:40 pm, Timothy Madden <terminato...@gmail.com> wrote:
> Can a new method std::exception::wcs_what() (or alike) be added to the
> standard library base exception class ?

In principle this should be possible. Since std::exception is intended
to be derived from, there will always be the (small) risk, that
someone
else has provided such a function with (a) a different meaning or (b)
with an incompatible return-type such that the derived class would
be ill-formed. This is no complete show-stopper, but just a question
of
minimizing risks versus taking advantages from the proposed
resolution.

One example where this risk had been accepted, was the addition of
the virtual functions

virtual iter_type do_get(iter_type, iter_type, ios_base&,
ios_base::iostate& err, long long& v) const;
virtual iter_type do_get(iter_type, iter_type, ios_base&,
ios_base::iostate& err, unsigned long long& v) const;

to the num_get facet.

> I find the current approach, that the what() string can be converted to a
> wstring for display, leaves the problem of transporting wide-character
error
> messages open, because:
>
>        - in most locales the narrow-character set is much smaller than
>          the wide-character set. So with a narrow string you can not
>          really transport wide characters.
>
>        - using a different charset than the one in the current locale,
>          like UTF-8, for the what() string, would require all libraries
>          (and catch sites) used in the program to know about and follow
>          such a convention, or otherwise would require that all catch
>          sites know about and detect specific instances of
>          std::exception that have the what() string encoded differently
>
> I think the ability to construct a runtime_error with a wchar_t *
argument,
> and a wcs_what() method in std::exception, would be a global solution for
> wide-character error messages (meaning different libraries/modules need
not
> follow a convention for what() strings and need not be changed).

In principle I agree. As of the current time schedule it probably
won't get into C++0x, but you might have chances for a TC or TR.
I suggest that you start writing a corresponding proposal paper
and pre-publish it in this newsgroup, to get eraly feedback on
possible problems with details of the suggested resolution.

> Also, a member function template in std::exception, like
>
> template<typename charT>
>   charT const *message_string();
>
> with a requirement to be specialized only for types char and wchar_t,
would
> be nice as the catch site could do:
>
> ...}
>
> catch (std::exception const &ex)
> {
>   basic_string<TCHAR> strError(ex.message_string<TCHAR>());
>
>   // log/output the string...
>   // ...}
>
> catch (...)
> {
>   basic_string<TCHAR> strError(_T("Application error"));
>
>   // ...
>
> }
>
> and then the application could be written to always use wchar_t, or to
> always use char, depending on the definition of TCHAR.

Wouldn't it suffice, if there would be a free function template
accepting a std::exception as argument and performing
the corresponding transformation?

I also believe that the return type cannot/should not be
charT const *, because of the question of the ownership
of these strings.

What about:

namespace std {

template<
 class charT,
 class traits = char_traits<charT>,
 class Allocator = allocator<charT>
>
basic_string<charT, traits, Allocator> what(const exception& e);

}

which would not unnecessarily blow-up the interface of
std::exception?

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Can a new method std::exception::wcs_what() (or alike) be added to the
> standard library base exception class ?

Hi,
I am not an expert in the matter, but I read somewhere that the intent
of member function what() is to provide a sort of index that can be
used to look up the error message in the dictionary. It is not
(necessarily) supposed to be the final error message. In fact it
shouldn't be exception's responsibility, or "thrower's" responsibility
to say how the final message looks like. Error messages can be
displayed in different languages...

Regards,
&rzej

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article
<e144480a-ea7d-4202-a957-6276e5538823@5g2000yqz.googlegroups.com>,
 restor <akrzemi1@gmail.com> wrote:

> > Can a new method std::exception::wcs_what() (or alike) be added to the
> > standard library base exception class ?
>
> Hi,
> I am not an expert in the matter, but I read somewhere that the intent
> of member function what() is to provide a sort of index that can be
> used to look up the error message in the dictionary. It is not
> (necessarily) supposed to be the final error message. In fact it
> shouldn't be exception's responsibility, or "thrower's" responsibility
> to say how the final message looks like. Error messages can be
> displayed in different languages...
>
> Regards,
> &rzej

Would you mind posting a link to the documentation/article in question?

Thanks,
Jon

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

=?ISO-8859-1?Q?Daniel_Kr=FCgler?= wrote:
>
> On Jul 21, 7:40 pm, Timothy Madden <terminato...@gmail.com> wrote:
>>
>> Can a new method std::exception::wcs_what() (or alike) be added to the
>> standard library base exception class ?
>
> In principle this should be possible.

[...]
>>
>> I think the ability to construct a runtime_error with a wchar_t *
>
> argument,
>>
>> and a wcs_what() method in std::exception, would be a global solution for
>> wide-character error messages (meaning different libraries/modules need
>
> not
>>
>> follow a convention for what() strings and need not be changed).
>
> In principle I agree. As of the current time schedule it probably
> won't get into C++0x, but you might have chances for a TC or TR.
> I suggest that you start writing a corresponding proposal paper
> and pre-publish it in this newsgroup, to get eraly feedback on
> possible problems with details of the suggested resolution.
>
>> Also, a member function template in std::exception, like
>>
>> template<typename charT>
>>  charT const *message_string();
>>
>> with a requirement to be specialized only for types char and wchar_t,
>
> would
>>
>> be nice

[...]

Thank you for this idea.

Somehow wcs_what() still strikes me as the natural wide-version of
what(), but if I must refrain from polluting the std::exception class
namespace than I would overload the already existing what() with a
member template function, able to also return the wide-character
message, like:

template<typename charT>
   charT const *std::exception::what();

that I could call as MessageBoxT(ex.what<TCHAR>());
Instantiating this member template function with any type other than
char or wchar_t, or overloading the what() member function, is
undefined (meaning application programs should never try this), just
to allow for future specializations without further pollution. :)

Of course, what<char>() is specified to return exactly the same
message as the non-template what(), and what<wchar_t>() is specified
to return the message converted to wide characters.

This also means that std::exception and all derived classes in the
library now shall take a wchar_t const * constructor, too.

Would a std::[w]string const & constructor also be good ?

About the std::string as a result type approach, people might object
that the std::string copy constructor can throw for no-memory, and I
find that they are right in that to handle exceptions you would have
to use a class that again throws them. Although everything is
possible, that would not be very nice.

Of course there is also the option to overload what() to take a
char/wchar_t argument (no template) that is not used (like for
operator ++(int)) and should be the null character, like this:

  char const *what()
  char const *what(char)
wchar_t const *what(wchar_t)

And then I would call ex.what(TCHAR()). But I think ex.what<TCHAR>()
looks better and does not need unused arguments.

While we are at this, can anyone see a problem with specifying a new
overload for main(), like:

int main()
int main(int argc, char          *argv[])
int main(int argc, char    const *argv[])
int main(int argc, wchar_t const *argv[])

that is, allow main to receive arguments as const and wide-character
const strings ?

Yes I know implementations have always been free to support whatever
overload for main() they see fit, and that this new form is likely to
be already there, but it would be good if the overload would also be
specified by the standard.

The rationale would be the same: converting the char *argv[] to
wide-strings still limits the string to the execution narrow-character
set, or otherwise leaves open the encoding for the char *argv[].


Would all these be good for a proposal paper ?

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 23 July, 20:56, Jonathan Jones <clcppm-pos...@this.is.invalid>
wrote:
> In article
> <e144480a-ea7d-4202-a957-6276e5538...@5g2000yqz.googlegroups.com>,
>
>  restor <akrze...@gmail.com> wrote:
> > > Can a new method std::exception::wcs_what() (or alike) be added to the
> > > standard library base exception class ?
>
> > Hi,
> > I am not an expert in the matter, but I read somewhere that the intent
> > of member function what() is to provide a sort of index that can be
> > used to look up the error message in the dictionary. It is not
> > (necessarily) supposed to be the final error message. In fact it
> > shouldn't be exception's responsibility, or "thrower's" responsibility
> > to say how the final message looks like. Error messages can be
> > displayed in different languages...
>
> > Regards,
> > &rzej
>
> Would you mind posting a link to the documentation/article in question?

http://www.boost.org/community/error_handling.html
Number 5 ("Don't worry too much about the what() message.")

Regards,
&rzej



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

restor wrote:
>>
>> Can a new method std::exception::wcs_what() (or alike) be added to the
>> standard library base exception class ?
>
> Hi,
> I am not an expert in the matter, but I read somewhere that the intent
> of member function what() is to provide a sort of index that can be
> used to look up the error message in the dictionary. It is not
> (necessarily) supposed to be the final error message. In fact it
> shouldn't be exception's responsibility, or "thrower's" responsibility
> to say how the final message looks like. Error messages can be
> displayed in different languages...
>

It looks to me like this is what /error codes/ are for.

However it looks like the library (and many other libraries) use
exception types instead of codes. Since error codes are expected to be
constants, they can be mapped to types. However when using exception
types and no codes, then every catch site has to:
       - either catch all types, to convert the type to an error code
         or message
               or
       - catch only std::exception and then use dynamic_cast<> to get
         the type and convert it to an error code or error message

So maybe this is the reason why the what() string is currently
entirely implementation-defined.

I must say I do not like dynamic_cast<> nor RTTI (I guess other
programmers feel the same), and I also do not like catching for all
possible types, on every catch site, and that is why I usually just
want the what() string in a message box or in some other error message
or error prompt. Furthermore, this is why when I get to write an
exception class or to throw one, I want to put a meaningful message
for the what() string.

One other reason why the what() message is still of interest, despite
the programmer having the error type at her disposal instead, is that,
let's face it, not everyone is concerned about translating every
possible error message, and because there can be libraries that just
report an error message and have no error code (which would be, of
course, bad practice for the library).

Maybe adding some codes to std::exception would be something to think
about, for example allowing a class string (to hold a library name,
for example "libpq" or "boost" or "xpcom") and a numeric code, that
indicates a specific error within the library given by the class
string.

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
>
> Hello
>
> Can a new method std::exception::wcs_what() (or alike) be added to the
> standard library base exception class ?
>
> I find the current approach, that the what() string can be converted to a
> wstring for display, leaves the problem of transporting wide-character error
> messages open, because:
>
>      - in most locales the narrow-character set is much smaller than
>        the wide-character set. So with a narrow string you can not
>        really transport wide characters.
>
>      - using a different charset than the one in the current locale,
>        like UTF-8, for the what() string, would require all libraries
>        (and catch sites) used in the program to know about and follow
>        such a convention, or otherwise would require that all catch
>        sites know about and detect specific instances of
>        std::exception that have the what() string encoded differently
>
> I think the ability to construct a runtime_error with a wchar_t * argument,
> and a wcs_what() method in std::exception, would be a global solution for
> wide-character error messages (meaning different libraries/modules need not
> follow a convention for what() strings and need not be changed).

Can a wstring / wchar_t * constructor for file-based streams also be added ?

There are systems with characters from the execution wide-character
set for file names, and trying to open these with a char * string
(converted from a wstring or not) for file names simply will not work.

Simple systems with filenames consisting only of characters from the
execution narrow-character set can convert the wstring to string (like
with wcstombs).

The point is that such a conversion would not be good enough for
modern computer systems with Unicode filenames, that need the wstring
directly.

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 3, 7:36 am, Timothy Madden <terminato...@gmail.com> wrote:
> Timothy Madden wrote:
>
> > Hello
>
> > Can a new method std::exception::wcs_what() (or alike) be added to the
> > standard library base exception class ?
>
> > I find the current approach, that the what() string can be converted to
a
> > wstring for display, leaves the problem of transporting wide-character
error
> > messages open, because:
>
> >      - in most locales the narrow-character set is much smaller than
> >        the wide-character set. So with a narrow string you can not
> >        really transport wide characters.
>
> >      - using a different charset than the one in the current locale,
> >        like UTF-8, for the what() string, would require all libraries
> >        (and catch sites) used in the program to know about and follow
> >        such a convention, or otherwise would require that all catch
> >        sites know about and detect specific instances of
> >        std::exception that have the what() string encoded differently
>
> > I think the ability to construct a runtime_error with a wchar_t *
argument,
> > and a wcs_what() method in std::exception, would be a global solution
for
> > wide-character error messages (meaning different libraries/modules need
not
> > follow a convention for what() strings and need not be changed).
>
> Can a wstring / wchar_t * constructor for file-based streams also be adde=
d
?
>
> There are systems with characters from the execution wide-character
> set for file names, and trying to open these with a char * string
> (converted from a wstring or not) for file names simply will not work.
>
> Simple systems with filenames consisting only of characters from the
> execution narrow-character set can convert the wstring to string (like
> with wcstombs).
>
> The point is that such a conversion would not be good enough for
> modern computer systems with Unicode filenames, that need the wstring
> directly.

The next library update of C++ will very probably consider to include
a component based on the boost library path. Any decision on possible
API changes of the filestreams should be deferred to this point.

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]