I'd just like to, if we can, get a consensus on the naming conventions for exceptions. Here're two to conjure with:

1. Trailing type word

    Errors are called TerminalThingError
    Exceptions are called SurprisingThingException

2. Prefix

    Errors are called ETerminalThing
    Exceptions are called XSurprisingThing

Frankly, I'm not really bothered which we go for, but I want to see if we can get an overall agreement, because I'm writing some exceptional code at the moment, and it would be nice not to have to go back and change all the names down the track.

Walter, can you make your feelings clear at this point, as this may help us all save a lot of hot air in debating options that you're going to veto?

Matthew

Forgot: the second part of this was whether the naming conventions *and* the error/exception hierarchy are finalised for Phobos itself? Until that is done, we'll be potentially wasting our effort in getting a 3rd-party convention, if the two are inconsistent

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhv5v3$14gl$1@digitaldaemon.com...
> I'd just like to, if we can, get a consensus on the naming conventions for exceptions. Here're two to conjure with:
>
> 1. Trailing type word
>
>     Errors are called TerminalThingError
>     Exceptions are called SurprisingThingException
>
> 2. Prefix
>
>     Errors are called ETerminalThing
>     Exceptions are called XSurprisingThing
>
> Frankly, I'm not really bothered which we go for, but I want to see if we can get an overall agreement, because I'm writing some exceptional code at the moment, and it would be nice not to have to go back and change all the names down the track.
>
> Walter, can you make your feelings clear at this point, as this may help
us
> all save a lot of hot air in debating options that you're going to veto?
>
> Matthew
>
>

Matthew Wilson wrote:

>     Errors are called TerminalThingError
>     Exceptions are called SurprisingThingException

I read through a Java book, and frankly i still don't understand why distinguish "exceptions" and "errors"? We have no conditions which cannot be caught in D.

-eye

I don't particularly care whether we use prefixes or suffixes. As long as its consistent, I can write my code either way.

--Benji Smith

On Wed, 20 Aug 2003 17:00:02 +1000, "Matthew Wilson" <matthew@stlsoft.org> wrote:

>I'd just like to, if we can, get a consensus on the naming conventions for exceptions. Here're two to conjure with:
>
>1. Trailing type word
>
>    Errors are called TerminalThingError
>    Exceptions are called SurprisingThingException
>
>2. Prefix
>
>    Errors are called ETerminalThing
>    Exceptions are called XSurprisingThing
>
>Frankly, I'm not really bothered which we go for, but I want to see if we can get an overall agreement, because I'm writing some exceptional code at the moment, and it would be nice not to have to go back and change all the names down the track.
>
>Walter, can you make your feelings clear at this point, as this may help us all save a lot of hot air in debating options that you're going to veto?
>
>Matthew
>

Errors are exceptions that you are not usually going to catch
so catch( Exception e ) { ... } will not catch Errors
catch( Error e ) { ... } will catch errors but allow exceptions to pass
in java you then have catch( Throwable t ) if you want to catch all
there are times when you want to catch errors and exit cleanly but allow
exceptions to be processed by the caller (where they will be catch, handled
and the app continue)

what constitutes Error or Exception depends on who and what your doing, indirecting via a null pointer for instance error or exception ? (or its own class)

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bhvi6o$1n6r$1@digitaldaemon.com...
> Matthew Wilson wrote:
>
> >     Errors are called TerminalThingError
> >     Exceptions are called SurprisingThingException
>
> I read through a Java book, and frankly i still don't understand why distinguish "exceptions" and "errors"? We have no conditions which cannot be caught in D.
>
> -eye

But do you have a preference?

I'm trying to get a consensus, and then we can all just work to that, rather than half of us having to go back and change classes all over the place.

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:u107kvor655cqk9scjt089v1toskgckpk4@4ax.com...
> I don't particularly care whether we use prefixes or suffixes. As long as its consistent, I can write my code either way.
>
> --Benji Smith
>
> On Wed, 20 Aug 2003 17:00:02 +1000, "Matthew Wilson" <matthew@stlsoft.org> wrote:
>
> >I'd just like to, if we can, get a consensus on the naming conventions
for
> >exceptions. Here're two to conjure with:
> >
> >1. Trailing type word
> >
> >    Errors are called TerminalThingError
> >    Exceptions are called SurprisingThingException
> >
> >2. Prefix
> >
> >    Errors are called ETerminalThing
> >    Exceptions are called XSurprisingThing
> >
> >Frankly, I'm not really bothered which we go for, but I want to see if we can get an overall agreement, because I'm writing some exceptional code
at
> >the moment, and it would be nice not to have to go back and change all
the
> >names down the track.
> >
> >Walter, can you make your feelings clear at this point, as this may help
us
> >all save a lot of hot air in debating options that you're going to veto?
> >
> >Matthew
> >
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bhv5v3$14gl$1@digitaldaemon.com...
| 2. Prefix
|
|     Errors are called ETerminalThing
|     Exceptions are called XSurprisingThing
|

My vote for this one

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19

I personally prefer the Exception/Error suffixes. They are explicit and clear.

However, someone could make a case that if classes were displayed alphabetically, all the error/exception classes would be grouped together. However, (imo) that is not necessarily true (i.e. XML parsing classes might get grouped within the X's). But if (hypothetically) you had a source code tool that displayed a list of classes, and the list could be grepped for "Error" and "Exception", then that would *really* display all the exceptional classes.

So I would "vote" for option 1.

Les Baker

"Les Baker" <lesbaker@innovaREMOVETHIS.net> wrote in message
news:bi19r3$14jt$1@digitaldaemon.com...
| I personally prefer the Exception/Error suffixes. They are explicit and
| clear.
|

If you're naming in english. If your names are in another language, having those suffixes would make your code unclear. That's why I chose the prefixes.

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19

I also vote for option 1 (postfix Exception/Error)
for two reasons:
 1) you know what the Object is (XMissingParam -v- MissingParamException )
     XMissingParam might be a phantom param object or similar
 2) prefixes mess with my brain. I find it realy hard reading code with lots
of prefixes, (Like hungarian notation) especialy when searching for where a
var/class is used inside a big file.
(yes I know ctrl-f get my editor to "find" but that jumps about, there are
times when I prefer to scan the flow of some code running it in my head to
see where the bugs are, the fewer prefixes the better).

"Les Baker" <lesbaker@innovaREMOVETHIS.net> wrote in message news:bi19r3$14jt$1@digitaldaemon.com...
> I personally prefer the Exception/Error suffixes. They are explicit and clear.
>
> However, someone could make a case that if classes were displayed alphabetically, all the error/exception classes would be grouped together. However, (imo) that is not necessarily true (i.e. XML parsing classes
might
> get grouped within the X's). But if (hypothetically) you had a source code tool that displayed a list of classes, and the list could be grepped for "Error" and "Exception", then that would *really* display all the exceptional classes.
>
> So I would "vote" for option 1.
>
> Les Baker
>