Hi!

I just read some source code of the phobos library. There is one important
issue that should be fixed
sooner than later:

All exceptions that are thrown need to have an error code and the error codes and exceptions need to be listed in the class description.

If the expections that are thrown do not have an error code, you cannot find out what error happened and you cannot translate the error message into an appropriate language.

-- 
Jan-Eric Duden

On Wed, 31 Mar 2004 09:07:50 +0200 (31/Mar/04 05:07:50 PM)
, Jan-Eric Duden <jeduden@whisset.com> wrote:

> Hi!
>
> I just read some source code of the phobos library. There is one important
> issue that should be fixed
> sooner than later:
>
> All exceptions that are thrown need to have an error code and the error
> codes and exceptions need to be listed in the class description.
>
> If the expections that are thrown do not have an error code, you cannot find
> out what error happened and you cannot translate the error message into an
> appropriate language.
>

Agreed!

I prefer to keep UI text external to the program code and look it up at runtime. The lookup mechanism is made a lot easier if there are codes or tags to use as keys to the text. It makes multi-language support a lot easier.

Embedded English UI text is a bit of a waste in programs that are used in non-English speaking environments.

-- 
Derek

I usually prefer to have both: a default english error message and an error
code.
The default message for quick-and-dirty hacks and debugging.
The error code for sophisticated feedback that is going to be presented to
the user by the UI in
some language.

-- 
Jan-Eric Duden
"Derek Parnell" <Derek.Parnell@psyc.ward> wrote in message
news:opr5ptkjcpu2m3b2@news.digitalmars.com...
> On Wed, 31 Mar 2004 09:07:50 +0200 (31/Mar/04 05:07:50 PM) , Jan-Eric Duden <jeduden@whisset.com> wrote:
>
> > Hi!
> >
> > I just read some source code of the phobos library. There is one
> > important
> > issue that should be fixed
> > sooner than later:
> >
> > All exceptions that are thrown need to have an error code and the error codes and exceptions need to be listed in the class description.
> >
> > If the expections that are thrown do not have an error code, you cannot
> > find
> > out what error happened and you cannot translate the error message into
> > an
> > appropriate language.
> >
>
> Agreed!
>
> I prefer to keep UI text external to the program code and look it up at runtime. The lookup mechanism is made a lot easier if there are codes or tags to use as keys to the text. It makes multi-language support a lot easier.
>
> Embedded English UI text is a bit of a waste in programs that are used in non-English speaking environments.
>
> -- 
> Derek

>I usually prefer to have both: a default english error message and an error
>code.
>The default message for quick-and-dirty hacks and debugging.
>The error code for sophisticated feedback that is going to be presented to
>the user by the UI in
>some language.
>

I usualy hate errorcodes. You can identify the error by the type that is thrown.

That depends on the design of the exception classes.
In order to have the same functionality that error codes provide,
then you need to have for every error a different class.
which might be the appropriate approach.

-- 
Jan-Eric Duden
"Matthias Becker" <Matthias_member@pathlink.com> wrote in message
news:c4duhn$oac$1@digitaldaemon.com...
> >I usually prefer to have both: a default english error message and an
error
> >code.
> >The default message for quick-and-dirty hacks and debugging.
> >The error code for sophisticated feedback that is going to be presented
to
> >the user by the UI in
> >some language.
> >
>
> I usualy hate errorcodes. You can identify the error by the type that is
thrown.
>
>

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:c4duhn$oac$1@digitaldaemon.com...
> >I usually prefer to have both: a default english error message and an
error
> >code.
> >The default message for quick-and-dirty hacks and debugging.
> >The error code for sophisticated feedback that is going to be presented
to
> >the user by the UI in
> >some language.
> >
>
> I usualy hate errorcodes.

When coding or when running a program? Error codes can have meaningful names for the coder. Error codes should always be converted to meaningful text for the user.

> You can identify the error by the type that is thrown.

If  this is true, then the object thrown IS the error code. However, because it is possible to throw the same object for different error conditions, it is not always true that if you know the thrown object you therefore know the error.

-- 
Derek

Matthias Becker wrote:
> I usualy hate errorcodes. You can identify the error by the type that is thrown.

But you cannot create a map that maps types to text strings.

Besides, you definitely need error codes if the error is merely passed along by the library. For example, a HTTP connection class will want to include the HTTP error code in the exceptions it throws.

Do you want to create a separate class for the hundreds of possible HTTP error codes? You'd also have to do a big switch before throwing the exception and then, on the other end, you'd have to do a long if/else to get the error code back from the type.

I prefer the error codes, thank you ;).

Hauke

"Jan-Eric Duden" <jeduden@whisset.com> wrote:

> That depends on the design of the exception classes.
> In order to have the same functionality that error codes provide,
> then you need to have for every error a different class.
> which might be the appropriate approach.

Or you could have a compromise. MFC, if I recall correctly, has a CException base class, and then a bunch of derived classes. CFileException, in particular, has an error code you can query to find out exactly what happened (end of file, out of disk space, etc.). I believe COleException is similar, but with different error codes related to COM/ActiveX.

And for the other extreme, ATL has only one exception, CAtlException, which has only one (meaningful) method to return the HRESULT. In general, ATL programmers frown on the use of exceptions, and I think this class design mirrors that philosophy.

-- 
dave