www.digitalmars.com         C & C++   DMDScript  

D - Exception naming conventions - Phobos, and third party libraries

reply "Matthew Wilson" <matthew stlsoft.org> writes:
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
Aug 20 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
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
Aug 20 2003
prev sibling next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
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
Aug 20 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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
Aug 20 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Mike Wynn wrote:

 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)


I still don't see much sense. I don't see any sense catching generic 
exceptions with a "blank" - that's what the surrounding environment 
should do. One should only catch exceptions one knows what to do with. 
I'd look for some other language's exception tree and see which makes 
more sense.


 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)


Then how may it be anchored in the standard library? :)

-eye
Aug 21 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bi2f6l$2rsc$1 digitaldaemon.com...

 Mike Wynn wrote:

 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)


 I still don't see much sense. I don't see any sense catching generic
 exceptions with a "blank" - that's what the surrounding environment
 should do. One should only catch exceptions one knows what to do with.
 I'd look for some other language's exception tree and see which makes
 more sense.


consider the situation, if an error occurs (usually non recoverable, or at
least sever programming error) you may want to exit (email or http the stack
trace off to the app vendor etc)
but exceptions you want to let pass to the caller that can deal with them
(recover).

the basic idea that you should only catch what you can deal with is still
here, I know how to deal with an `error` I want to exit (exception like file
unopenable 'cos its read only and I want read/write) I'm not bothered about,
the caller should be expecting that posibility that they will be thrown and
deal with them there.

I guess its more transaction processing that apps, where exception are
things you can recover from, errors are not, like you've just scribbled all
over your stack frame(s) so you can not continue as any further actions are
undefined.


 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)


 Then how may it be anchored in the standard library? :)


isn't that what we are discussing ?
to me it should be
Thing that can be thrown (base class to allow the system or use to throw
things that are not intended for anyone to catch)
Error : very sever problem, indicating that what every you where doing has
either caused the system to become unstable (like a stack scribble, may be a
stack under/overflow) or unrecoverable [ not only has your IP connections
closed with error but the host is now unreachable.
D Runtime Exception : your code is either wrong, or your using Exceptions in
and "interesting" way (see example at the end)
Exception : an unexpected event, intended to be caught, such as file is read
only, when you try to open r/w.

as an aside, Null Pointer and Array Bounds exceptions I believe in D they
are only in debug builds is this right ?

one of the early java "optimisations" was to do
int i=0;
try {
    while( true ) process( array[i++] );
}catch( ArrayBoundsException e ) {
    // we got to the end ..
}
instead of
for( int i = 0; i < array.length; i++ ) process[i++];
as this is slower (2 checks on i < array.length) on long arrays

also null pointer exceptions are great for lazy member creation;
int getSomethingFromFoo() {
    try {
        return foo.getSomething();
    } catch ( NullPointerException e ) {
        return (foo = new Foo()).getSomething();
    }
}
or for the thread safe
int getSomethingFromFoo() {
    try {
        return foo.getSomething();
    } catch ( NullPointerException e ) {
        synchronized( this ) {
            return (foo = (foo!=null)? foo: new Foo()).getSomething();
        }
    }
}

so is this use of exceptions "valid" or should the Null pointer and Array
bounds thrown thing be considered Errors as they are most likely programming
errors not exceptions to normal processing like FileNotFound etc.
Aug 21 2003
prev sibling next sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
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
Aug 20 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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
Aug 20 2003
parent Benji Smith <dlanguage xxagg.com> writes:
I suppose if I had to have a preference, it would be a suffix (since that's what
I've been using all along), along the lines of DomException and StackException.
It's more consistent with the Java way of doing things, and that's what I'm used
to.

--Benji Smith

In article <bi0sdf$h7f$1 digitaldaemon.com>, Matthew Wilson says...

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
Aug 20 2003
prev sibling next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"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
Aug 20 2003
prev sibling next sibling parent reply "Les Baker" <lesbaker innovaREMOVETHIS.net> writes:
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
Aug 20 2003
next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"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
Aug 20 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bi1cm0$18n0$1 digitaldaemon.com...

 "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


you only need to learn two english words ... Exception and Error.
GGyyffSSException  or HHggyHiaJJhError
where as XGGyyffSS or EHHggyHiaJJh  only the person who speak that lang can
understand
if X... is an exception or a X windows Class or Xwhateverelsethingy
Aug 20 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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
Aug 20 2003
prev sibling next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhv5v3$14gl$1 digitaldaemon.com>, Matthew Wilson 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


Do we really need to have either?

3. No prefix nor suffix

    Errors are called TerminalThing
    Exceptions are called SurprisingThing

Why? Because I like simplicity and hate stating the obvious when there
is no need to. If we take look at, for example, Java, we notice that if
you remove the Exception from most of the Exception classes, it's
perfectly clear that we're talking about an exception, and the same goes
for errors. How about these:

FileNotFound
UnknownHost
BadLocation
IllegalAccess
DestroyFailed
IllegalArgument
NullPointer
ExceptionInInitializer
StackOverflow
OutOfMemory
ThreadDeath

All of those exist in Java 1.4.2's Throwable tree, some with Exception
and some with Error suffix (one of them has no suffix at all!) Guess
which ones are errors and which ones are exceptions and see if you can
get them right.

So how would dropping Errors and Exceptions feel like? Let's see:

void compilerFrontEnd()
{
    try
    {
        parseSomeCode(filename);
    }
    catch (FileNotFound notfound)
    {
        printMessageAndQuit("File " ~ notfound.filename ~ " not found");
    }
    catch (SyntaxError error) // not an error despite the name, but an exception
    {
        printMessageAndQuit("Syntax error at line " ~ error.line);
    }
    catch (EndOfFile eof)
    {
        printMessageAndQuit("Unexpected end of file at line " ~ eof.line);
    }

    // ...
}

You wouldn't otherwise make classes like EndOfFile, SyntaxError or
FileNotFound, so there would be no name clashes, right?

An exception (no pun intended) for this "leave the suffix out" rule
would be those errors and exceptions that don't have a specific nature
after which to name them; for example, I'd consider the following Java
exceptions just fine: DataFormatException, IOException (but still I'd
prefer its subclass End_Of_File over EOFException), SQLException,
AssertionError (or AssertionException, or maybe just AssertFailed),
RuntimeException, LinkageError and AWTError.

Division between Errors and Exceptions is ok although disputable since
the programmer might decide to decide for himself which exceptions are
errors and which are not (alas, the inheritance tree cannot be changed
at will.) For example, an assertion could be an exception for one and an
error for another.

Still, if you decide to go for prefix or suffix, I'd really prefer the
suffix. Hungarian notation, Microsoft APIs and Symbian programming are
three good reasons not to walk the disgusting road of arbitrary
one-letter obfuscation prefixes.

-Antti
Aug 23 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.

"Antti Sykäri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbkfa5v.bar.jsykari pulu.hut.fi...

 In article <bhv5v3$14gl$1 digitaldaemon.com>, Matthew Wilson 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


 Do we really need to have either?

 3. No prefix nor suffix

     Errors are called TerminalThing
     Exceptions are called SurprisingThing

 Why? Because I like simplicity and hate stating the obvious when there
 is no need to. If we take look at, for example, Java, we notice that if
 you remove the Exception from most of the Exception classes, it's
 perfectly clear that we're talking about an exception, and the same goes
 for errors. How about these:


    That's perfect! There's no need to state inheritance hierarchy in the
class' name.


 FileNotFound
 UnknownHost
 BadLocation
 IllegalAccess
 DestroyFailed
 IllegalArgument
 NullPointer
 ExceptionInInitializer
 StackOverflow
 OutOfMemory
 ThreadDeath

 All of those exist in Java 1.4.2's Throwable tree, some with Exception
 and some with Error suffix (one of them has no suffix at all!) Guess
 which ones are errors and which ones are exceptions and see if you can
 get them right.

 So how would dropping Errors and Exceptions feel like? Let's see:

 void compilerFrontEnd()
 {
     try
     {
         parseSomeCode(filename);
     }
     catch (FileNotFound notfound)
     {
         printMessageAndQuit("File " ~ notfound.filename ~ " not found");
     }
     catch (SyntaxError error) // not an error despite the name, but an


exception

     {
         printMessageAndQuit("Syntax error at line " ~ error.line);
     }
     catch (EndOfFile eof)
     {
         printMessageAndQuit("Unexpected end of file at line " ~ eof.line);
     }

     // ...
 }

 You wouldn't otherwise make classes like EndOfFile, SyntaxError or
 FileNotFound, so there would be no name clashes, right?

 An exception (no pun intended) for this "leave the suffix out" rule
 would be those errors and exceptions that don't have a specific nature
 after which to name them; for example, I'd consider the following Java
 exceptions just fine: DataFormatException, IOException (but still I'd
 prefer its subclass End_Of_File over EOFException), SQLException,
 AssertionError (or AssertionException, or maybe just AssertFailed),
 RuntimeException, LinkageError and AWTError.


    I guess we could turn DataFormatException into InvalidDataFormat, and
have a hierarchy for assertion failures, according to the place they occur:
AssertionFailed, InvariantBroken, InContractFailure, OutContractFailure.


 Division between Errors and Exceptions is ok although disputable since
 the programmer might decide to decide for himself which exceptions are
 errors and which are not (alas, the inheritance tree cannot be changed
 at will.) For example, an assertion could be an exception for one and an
 error for another.


    I think the distinction between Errors and Exceptions are quite clear,
if we follow the Java Language Specification terminology: Exceptions are
recoverable, while Errors are a way to the runtime tell you it's going to
die and the reason for it. We can't recover gracefully from a OutOfMemory or
a StackOverflow, IMO.


 Still, if you decide to go for prefix or suffix, I'd really prefer the
 suffix. Hungarian notation, Microsoft APIs and Symbian programming are
 three good reasons not to walk the disgusting road of arbitrary
 one-letter obfuscation prefixes.

 -Antti


    Best regards,
    Daniel Yokomiso.

"In theory, there is no difference between theory and practice.  But, in
practice, there is."
 - Jan L. A. van de Snepscheut


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/8/2003
Aug 23 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Daniel Yokomiso wrote:

 
 Hi,
 
     Comments embedded.
 
 "Antti Sykäri" <jsykari gamma.hut.fi> escreveu na mensagem
 news:slrnbkfa5v.bar.jsykari pulu.hut.fi...

 In article <bhv5v3$14gl$1 digitaldaemon.com>, Matthew Wilson 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






I would prefer exactly this.


 2. Prefix

     Errors are called ETerminalThing
     Exceptions are called XSurprisingThing






Abbreviations are evil (in general). 


 Do we really need to have either?

 3. No prefix nor suffix

     Errors are called TerminalThing
     Exceptions are called SurprisingThing

 Why? Because I like simplicity and hate stating the obvious when there
 is no need to. If we take look at, for example, Java, we notice that if
 you remove the Exception from most of the Exception classes, it's
 perfectly clear that we're talking about an exception, and the same goes
 for errors. How about these:


 
     That's perfect! There's no need to state inheritance hierarchy in the
 class' name.


In general: yes. But with respect to certain structural elements: no.

It's important to be able to focus e. g. all Error and Exception handling
in a project. The only efficient way to do so is be text search for the
words "Error" or "Exception". 
 

 ...
     I think the distinction between Errors and Exceptions are quite clear,
 if we follow the Java Language Specification terminology: Exceptions are
 recoverable, while Errors are a way to the runtime tell you it's going to
 die and the reason for it. We can't recover gracefully from a OutOfMemory or
 a StackOverflow, IMO.


Of course one could recover from OutOfMemory if one wants to. 
We do in the following example:

Let's assume you cache images in a multimedia application. Let's say you have
XX MB LRU images there. You don't need them but it makes your application
faster.
If you run out of memory, you use a hook within malloc, that frees images 
according to the size requested and retries the malloc. Pretty easy.


 Still, if you decide to go for prefix or suffix, I'd really prefer the
 suffix. Hungarian notation, Microsoft APIs and Symbian programming are
 three good reasons not to walk the disgusting road of arbitrary
 one-letter obfuscation prefixes.




It's a question of language, consistency and standards. We currently have 
neither. It seems that most contributors would rather borrow from Java.
I think that D and Java are so different in philosophy that imitating
Java language might even cripple D APIs. 

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Aug 24 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,
    Comments embedded.

"Helmut Leitner" <helmut.leitner chello.at> escreveu na mensagem
news:3F4868D7.9FE75B14 chello.at...

 Daniel Yokomiso wrote:


[snip]


     That's perfect! There's no need to state inheritance hierarchy in




the

 class' name.


 In general: yes. But with respect to certain structural elements: no.

 It's important to be able to focus e. g. all Error and Exception handling
 in a project. The only efficient way to do so is be text search for the
 words "Error" or "Exception".


    Or use a tool to do structural search for Error and Exception. Once the
D syntax get stable and we have a general parser for it, we could create (I
am volunteering to write this) a framework for searching, refactoring, etc.
There's no need to do these things if exist tools for that (either graphic
or textual).


 ...
     I think the distinction between Errors and Exceptions are quite




clear,

 if we follow the Java Language Specification terminology: Exceptions are
 recoverable, while Errors are a way to the runtime tell you it's going




to

 die and the reason for it. We can't recover gracefully from a




OutOfMemory or

 a StackOverflow, IMO.


 Of course one could recover from OutOfMemory if one wants to.
 We do in the following example:

 Let's assume you cache images in a multimedia application. Let's say you


have

 XX MB LRU images there. You don't need them but it makes your application


faster.

 If you run out of memory, you use a hook within malloc, that frees images
 according to the size requested and retries the malloc. Pretty easy.


    That means that there are still referenced images around, so you'll need
some way to re-cache them when requested. But what will happen if after
requesting a freed image your system goes out of memory again? What if you
can't free some images because they're on display? Catching the OutOfMemory
and trying to recover from it can become pretty tricky. For these cases I
think that the best is to use WeakReferences for the images, so we can
reload them as needed but if there's few memory the system will free some of
them. Of course this won't happen when the second (and inevitable)
OutOfMemory occurs, but makes your algorithm clearer.


 Still, if you decide to go for prefix or suffix, I'd really prefer the
 suffix. Hungarian notation, Microsoft APIs and Symbian programming are
 three good reasons not to walk the disgusting road of arbitrary
 one-letter obfuscation prefixes.




 It's a question of language, consistency and standards. We currently have
 neither. It seems that most contributors would rather borrow from Java.
 I think that D and Java are so different in philosophy that imitating
 Java language might even cripple D APIs.


    Here we are talking about naming conventions. There's no problem in
following Java naming conventions in D. Of course we won't follow the
library design, because we have better mechanisms for several idioms.


 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com


    Best regards,
    Daniel Yokomiso.

"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence."
- Jeremy S. Anderson


---
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: 19/8/2003
Aug 24 2003
next sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
Daniel Yokomiso wrote:

 It's important to be able to focus e. g. all Error and Exception handling
 in a project. The only efficient way to do so is be text search for the
 words "Error" or "Exception".


 
     Or use a tool to do structural search for Error and Exception. Once the
 D syntax get stable and we have a general parser for it, we could create (I
 am volunteering to write this) a framework for searching, refactoring, etc.
 There's no need to do these things if exist tools for that (either graphic
 or textual).


While these tools do not exist or aren't in a perfect state, it's good to
be able to rely on good old text search. Why not keep it simple?

I often found the tools fall short when you leave their path. E.g. 
  - if you want to search a project that doesn't compile
  - if you want to search multiple projects 
  - if you want to search through many revisions of the same project
 

 ...
     I think the distinction between Errors and Exceptions are quite




 clear,

 if we follow the Java Language Specification terminology: Exceptions are
 recoverable, while Errors are a way to the runtime tell you it's going




 to

 die and the reason for it. We can't recover gracefully from a




 OutOfMemory or

 a StackOverflow, IMO.


 Of course one could recover from OutOfMemory if one wants to.
 We do in the following example:

 Let's assume you cache images in a multimedia application. Let's say you


 have

 XX MB LRU images there. You don't need them but it makes your application


 faster.

 If you run out of memory, you use a hook within malloc, that frees images
 according to the size requested and retries the malloc. Pretty easy.


 
     That means that there are still referenced images around, so you'll need
 some way to re-cache them when requested. 


Yes of course. Such a cache has to hold the path to the image file to reload it.
Display functions ask the cache (like CachePathRetImage) for the image object.


 But what will happen if after
 requesting a freed image your system goes out of memory again? 


It will free older images and retry the memory request. If the cache is
(all chaches are) empty, the the request really fails.

There are usually many items in an application that are held in memory for
time efficiency reasons and that could be freed if necessary. Typically these
things are ignored on todays 256+ MB virtual memory PCs. ut you didn't ignore
this when you did multimedia CDs for 16-64 MB PCs. I think you won't ever 
ignore it on systems with limited memory (embedded, pda, e-book) or systems
that mix gigantic objects (like 600 dpi truecolor scans) with normal memory
usage.


 What if you can't free some images because they're on display? 


You can free them anyway. Being on the display doesn't mean that you need
their info to redraw them. You could have a long HTML-like window where you
scroll up and down over many images. The most recently redrawn and cached
and quick. The other are loaded and cached on demand.


 Catching the OutOfMemory
 and trying to recover from it can become pretty tricky. For these cases I
 think that the best is to use WeakReferences for the images, so we can
 reload them as needed but if there's few memory the system will free some of
 them. Of course this won't happen when the second (and inevitable)
 OutOfMemory occurs, but makes your algorithm clearer.


This is exactly that kind of Java thinking that I think is dangerous. 
WeakReferences and the whole system built around them in Java are extremely
tricky and only solve a selfmade problem. If we follow Java paths then we
will end where Java is. Bloated.

BTW there are other systems that use emergency memory pools (Perl) to
be able to recover or to be at least able to output dying message in
an OO environment gracefully.

Start a Java Swing application within 20 MB memory limits. It used to
just die without giving any any information about the reason. It will just
stop working (or end in loop).
 

 Still, if you decide to go for prefix or suffix, I'd really prefer the
 suffix. Hungarian notation, Microsoft APIs and Symbian programming are
 three good reasons not to walk the disgusting road of arbitrary
 one-letter obfuscation prefixes.




 It's a question of language, consistency and standards. We currently have
 neither. It seems that most contributors would rather borrow from Java.
 I think that D and Java are so different in philosophy that imitating
 Java language might even cripple D APIs.


 
     Here we are talking about naming conventions. There's no problem in
 following Java naming conventions in D. Of course we won't follow the
 library design, because we have better mechanisms for several idioms.


I'm not quite sure that I know what you mean in detail.
Could you start a comparision chart for these machanisms/idioms?
It would be a good basis for library design.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Aug 25 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Helmut Leitner" <leitner hls.via.at> escreveu na mensagem
news:3F49C52E.801A1879 hls.via.at...

 Daniel Yokomiso wrote:

 It's important to be able to focus e. g. all Error and Exception






handling

 in a project. The only efficient way to do so is be text search for






the

 words "Error" or "Exception".


     Or use a tool to do structural search for Error and Exception. Once




the

 D syntax get stable and we have a general parser for it, we could create




(I

 am volunteering to write this) a framework for searching, refactoring,




etc.

 There's no need to do these things if exist tools for that (either




graphic

 or textual).


 While these tools do not exist or aren't in a perfect state, it's good to
 be able to rely on good old text search. Why not keep it simple?

 I often found the tools fall short when you leave their path. E.g.
   - if you want to search a project that doesn't compile
   - if you want to search multiple projects
   - if you want to search through many revisions of the same project


"old text search" fall short on several issues:
   - if you want to search for instances of some class or it's subclasses
   - trying to find all callers of a certain method through certain
interface
   - giving a useful summary of available methods through an class/interface
(like the Eiffel "short" tool).

Plain textual search is useful, but if you want to do more comprehensive
searches you need either to adopt a naming convention (appending or
prepending names/letters) or try to come up with some regex to match what
you're are looking for.


 Yes of course. Such a cache has to hold the path to the image file to


reload it.

 Display functions ask the cache (like CachePathRetImage) for the image


object.

 But what will happen if after
 requesting a freed image your system goes out of memory again?


 It will free older images and retry the memory request. If the cache is
 (all chaches are) empty, the the request really fails.

 There are usually many items in an application that are held in memory for
 time efficiency reasons and that could be freed if necessary. Typically


these

 things are ignored on todays 256+ MB virtual memory PCs. ut you didn't


ignore

 this when you did multimedia CDs for 16-64 MB PCs. I think you won't ever
 ignore it on systems with limited memory (embedded, pda, e-book) or


systems

 that mix gigantic objects (like 600 dpi truecolor scans) with normal


memory

 usage.


 What if you can't free some images because they're on display?


 You can free them anyway. Being on the display doesn't mean that you need
 their info to redraw them. You could have a long HTML-like window where


you

 scroll up and down over many images. The most recently redrawn and cached
 and quick. The other are loaded and cached on demand.


 Catching the OutOfMemory
 and trying to recover from it can become pretty tricky. For these cases




I

 think that the best is to use WeakReferences for the images, so we can
 reload them as needed but if there's few memory the system will free




some of

 them. Of course this won't happen when the second (and inevitable)
 OutOfMemory occurs, but makes your algorithm clearer.


 This is exactly that kind of Java thinking that I think is dangerous.
 WeakReferences and the whole system built around them in Java are


extremely

 tricky and only solve a selfmade problem. If we follow Java paths then we
 will end where Java is. Bloated.


It's strange, because I think that making malloc catch an OutOfMemory and
decide to drop some arbitrarily chosen objects and then retry the malloc is
a tricky hack. It's the HOW not the WHY. WeakReferences exist in other OO
languages, rather than Java (Eiffel and Smalltalk come to mind) and they
model object references that can be freed if memory is too low. Just what
our problem is.


 BTW there are other systems that use emergency memory pools (Perl) to
 be able to recover or to be at least able to output dying message in
 an OO environment gracefully.


There are other kinds of Error possible in Java, most of the time its a bad
idea to try to catch them and continue.


 Start a Java Swing application within 20 MB memory limits. It used to
 just die without giving any any information about the reason. It will just
 stop working (or end in loop).


This is a problem of the bloated implementation of the Java VM and the Swing
framework. Try to compile a C++ problem and link it with all libraries you
can't find, and make sure to call at least one method of each inside a big
initialization block before your main method. Java sucks because they have
lots of interdependent libraries, not because it's the way it handles
memory. If they designed the Swing properly it would be fast (look at
Smalltalk GUIs, fast, tight (somewhat) and purely-object oriented) and
tight, dynamic allocation whatsoever. There's a paper (IIRC named "Compiling
Java to high-performance") talking about some specific changes to the Java
compiler (mostly to simulate structs and such) to improve Java performance
regarding numeric intensive applications. They give figures of 80% of
Fortran speed.


     Here we are talking about naming conventions. There's no problem in
 following Java naming conventions in D. Of course we won't follow the
 library design, because we have better mechanisms for several idioms.


 I'm not quite sure that I know what you mean in detail.
 Could you start a comparision chart for these machanisms/idioms?
 It would be a good basis for library design.


I'm writing an article to illuminate such differences. The most important is
the delegate feature in D, because it's fairly simple to use (i.e. no much
typing when compared to Java) there's more incentive for library writers and
programmers to offer higher-order algorithms:


list = list.filter(delegate bool(int n) {return n > 10;});

mutex.withDo(delegate void() {
    printf("I'm thread-safe!\r\n");
});

connection.withDo(delegate void() {
    connection.withStatementDo("SELECT * FROM FOO WHERE BAR = BAZ",
        delegate void(Statement stmt) {
            stmt.withResultSetDo(delegate void(ResultSet rs) {
                rs.doAll(&print);
            });
        }
    );
});


    The last two example uses the "withDo" idiom, common from Lisp (they use
"with_***_do" macros instead), to ensure that the resource is properly
initialized, the block executed, and then the resource is finalized
(something like RAII, but more general).
    Templates also give us many interesting ideas, allowing us to write more
generic code.


 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com



---
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: 19/8/2003
Aug 25 2003
prev sibling parent Helmut Leitner <leitner hls.via.at> writes:
Daniel Yokomiso wrote:

 
 Hi,
     Comments embedded.
 
 "Helmut Leitner" <helmut.leitner chello.at> escreveu na mensagem


I recently saw this a number of times from different contributors
obviously as a result from the top/bottom discussion.

But I think it isn't helpful. If there is no top comment any reader
will automatically assume that there are embedded comments.

There is no need to comment the obvious. 

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Aug 25 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Helmut Leitner wrote:


    That's perfect! There's no need to state inheritance hierarchy in the
class' name.





 In general: yes. But with respect to certain structural elements: no.
 
 It's important to be able to focus e. g. all Error and Exception handling
 in a project. The only efficient way to do so is be text search for the
 words "Error" or "Exception". 


Searching for "throw" and "catch" should be enough



 Of course one could recover from OutOfMemory if one wants to. 
 We do in the following example:


One can in C++, and in D, but in Java this might not work anyway. If the 
guys have decided that OutOfMemory means deth, so it probably does... :)


 It's a question of language, consistency and standards. We currently have 
 neither. It seems that most contributors would rather borrow from Java.
 I think that D and Java are so different in philosophy that imitating
 Java language might even cripple D APIs.


There is a beginning of a coding standard, which is initiated by Walter 
and mimics Java - probably just because people are familiar with it.

-eye
Aug 26 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <biguio$ki5$1 digitaldaemon.com>, Ilya Minkov wrote:

 Helmut Leitner wrote:
 

    That's perfect! There's no need to state inheritance hierarchy in the
class' name.




 

 In general: yes. But with respect to certain structural elements: no.
 
 It's important to be able to focus e. g. all Error and Exception handling
 in a project. The only efficient way to do so is be text search for the
 words "Error" or "Exception". 


 
 Searching for "throw" and "catch" should be enough


And, if you're searching for the exception classes' definitions,
searching for Exception and Error should be enough, since they will
derive from either of those classes anyway.

-Antti
Aug 27 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Do you mean that we can search for, say, OutOfMemory by virtue of its
inheritance relationship to, say, Error, as in

  class OutOfMemory
    : Error

then this is not really tenable. First, people declare inheritance in
several ways

class OutOfMemory : Error

or

class OutOfMemory :
 Error

or (the correct way :-)

class OutOfMemory
  : Error

Of course any decent source search tool can easily handle that. However,
what about the (extremely likely) case of a deep inheritance hierarchy (OT:
exceptions are about the only place where deep inheritance hierarchies are
appropriate IMAE)

class SystemXxxx
    : Error

class Win32Xxxx
    : SystemXxxx

class OutOfMemory
    : Win32Xxxx

class VirtualMemory
    : OutOfMemory

This may not be the most accurate anticipation of a future hierarchy, but
you can *guarantee* that there will be analogous ones. There are now several
problems to the
"nameless error/exception" plan.

 1. Your tool will have to be pretty smart to deduce up four levels that
VirtualMemory is an Error. Most people do, and will continue to do, use
grep.
 2. The names for SystemXxxx and Win32Xxxx are written thus because I can't
think of a decent name for them, other than SystemError and Win32Error. I
can't very well call them System and Win32, can I? And if we call do call
them SystemError and Win32Error - given that that's *exactly* what they
are - then isn't it inconsistent and confusing to use the non-appended names
OutOfMemory and VirtualMemory?

In any exception hierarchies, the vast bulk of the classes describe an
action/event that is shared by several components, and experience in a
multititude of manners. Of course, there are specific (leaf-node) exceptions
to this, such as BadIndexException, which may very well be named just
BadIndex. But IOException is a type we most certainly want in our exception
hierarchy. If it does not have the appended Exception, what do we call it?
IO? That is misleading. It is an IO exception, so should be called
IOException. Calling a leaf node type InvalidFilePermissionsException may be
over egging the pudding (although I don't actually agree that it is), but it
is consistent with the names of non-leaf nodes which must, in general,
comprise the "area" + "Exception"/"Error"

Of course, if I've misunderstood your intent, then I've just wasted a few
thousand brain cells. ;)

Matthew

"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbkqak3.s51.jsykari pulu.hut.fi...

 In article <biguio$ki5$1 digitaldaemon.com>, Ilya Minkov wrote:

 Helmut Leitner wrote:


    That's perfect! There's no need to state inheritance hierarchy in








the

class' name.





 In general: yes. But with respect to certain structural elements: no.

 It's important to be able to focus e. g. all Error and Exception






handling

 in a project. The only efficient way to do so is be text search for the
 words "Error" or "Exception".


 Searching for "throw" and "catch" should be enough


 And, if you're searching for the exception classes' definitions,
 searching for Exception and Error should be enough, since they will
 derive from either of those classes anyway.

 -Antti
Aug 27 2003
next sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
Thank goodness for people like Matthew Wilson, who can express things so well. I
agree with this argument 156000%, but the best I could come up with until now
has been "it's just better that way."

I am now officially changing my reason for voting for error/excpetion suffixes.

Thanks, Matt.

--Benji Smith
Aug 27 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
You are TOO generous by half!

I'm just a raggedy-brained f-wit most of the time. I just happened to hit a
small bit of mental clarity at the same time as getting the hump with the
debate. I decided in favour of polite, though comprehensive, explanation
rather than any more of my unpopular curt retorts.

So Benji, maybe we can add you to the list of probably buyers of my putative
D book, which takes the grand total to 18, IIRC. ;)


"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bijf40$1hko$1 digitaldaemon.com...

 Thank goodness for people like Matthew Wilson, who can express things so


well. I

 agree with this argument 156000%, but the best I could come up with until


now

 has been "it's just better that way."

 I am now officially changing my reason for voting for error/excpetion


suffixes.

 Thanks, Matt.

 --Benji Smith
Aug 27 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Matthew Wilson wrote:

 So Benji, maybe we can add you to the list of probably buyers of my putative
 D book, which takes the grand total to 18, IIRC. ;)


You can add me to the list. Adds up to 19. :-)

BTW congratulations to your excellent performance comparision articles.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Aug 27 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 You can add me to the list. Adds up to 19. :-)


You guys .... <G>

Helmut, I've locked your offer of reviewer in the vault, so don't think you
can escape. (Believe me, being a book reviewer isn't all fun-and-games.
Having been on both sides it's certainly easier to be a reviewer, but it's
no cake walk!)


 BTW congratulations to your excellent performance comparision articles.


Many thanks. :)

btw, if anyone wants to see (i) the updates with .NET SDK 1.1 and/or (ii)
the next installments in the series (some heavy container and comms
studies), you need to email the WDN editor
(http://windevnet.com/wdn/contact/) and let them know.
Aug 28 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bijavc$1bnf$1 digitaldaemon.com>, Matthew Wilson wrote:
[snip]

 Of course any decent source search tool can easily handle that. However,
 what about the (extremely likely) case of a deep inheritance hierarchy (OT:
 exceptions are about the only place where deep inheritance hierarchies are
 appropriate IMAE)
 
 class SystemXxxx
     : Error
 
 class Win32Xxxx
     : SystemXxxx
 
 class OutOfMemory
     : Win32Xxxx
 
 class VirtualMemory
     : OutOfMemory


Perhaps I should have stated my suggestion more clearly.

I am not at all of the opinion that we should drop Exception and Error
from those names where they naturally belong. In fact, this inheritance
hierarchy would be a perfect example of using names Exception and Error
precisely where they fit well and not using them where they don't:

(Forgive me for switching the places of OutOfMemory and
VirtualMemoryError -- I believe the hypothetical hierarchy looks more
realistic this way)

class SystemError : Error

class Win32Error : SystemError

class VirtualMemoryError : Win32Error

class OutOfMemory : VirtualMemoryError
class GeneralProtectionFault : VirtualMemoryError
class IllegalOperation : VirtualMemoryError

I agree that the non-leaf nodes of the inheritance hierarchy tend to
describe errors of a general domain, and the proper name for them is
"area" + "Exception"/"Error".

But the leaf nodes often mean just one particular error condition, in
which case it has a name that already indicates what kind of a creature
it is. IndexOutOfBounds? An exception. StackOverflow? An error.
ObjectFactoryBuilder? Uh, neither. But that's obvious. And so on.
Besides, there wouldn't be a lot of them, not at least in the standard
library, at least if it wouldn't grow too bloated. You could probably
memorize them if you wanted.

And no one said that XXXException wouldn't be a valid leaf exception
class -- certainly it is if there is no better name.
AuthenticationException, for example, is a perfectly good name for a
class if you don't know the particular reason (or don't care about
differentiating them) for an exception that an authentication module
just throwed.

The fundamental point is: I would prefer catching DivisionByZero instead
of DivisionByZeroException and StackOverflow instead of
StackOverflowError, because in these particular cases stating the
obvious -- that we're talking about an exception or an error -- seems
just too redundant. It feels as if you named application's main function
mainFunction() instead of main() or its arguments (String[]
argumentStrings) instead of (String[] args). Or used the horrid
CSomeClass prefix or any sort of hungarian notation.

(Which is, of course, a matter of personal opinion.)

But I agree that maybe, just maybe, a little extra typing would be
better than having to think whether to put in the extra Exception or
not. Consistency tends to be a good thing. After all, I'm programming in
a statically typed language where you need to keep stating the obvious,
and I even consider that a good thing. Besides, most IDEs and editors
have auto-completion for us lazy typers...


  1. Your tool will have to be pretty smart to deduce up four levels that
 VirtualMemory is an Error. Most people do, and will continue to do, use
 grep.


This is a stunningly valid argument.

Even though I think that non-leaf exception classes should mostly be
called XXXError or YYYException, and so the leaf nodes would have to
derive from a class that has one of those endings, and therefore 
"grep -B1 Error *.d" would indeed find most if not all of them. But this
would not be 100% bullet-proof, firstly because you really don't *have*
to specify the base class in the same or the next line to make it
compile, secondly because that switch works only in GNU grep, and
thirdly because 90% of people would not bother to use or learn that
switch, let alone have an opportunity to use a more sophisticated source
browsing system.

How often do you want to grep for all exceptions? (It's been ages since
I've used them in a real project; lately I've been working with systems
that don't support exceptions, so I don't really remember what to answer
myself.)

-Antti
Aug 28 2003
next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
[Me ranting, just a while ago:]


 It feels as if you named application's main function mainFunction()
 instead of main() or its arguments (String[] argumentStrings) instead
 of (String[] args). Or used the horrid CSomeClass prefix or any sort
 of hungarian notation.


[Meanwhile, in another thread far far away in a distant galaxy:]


I wouldn't mind standardizing on some names like sint8, sint16, uint32,
uint64, because 90% of all projects have those kind of typedefs.


C99 already standardized this why invent different names?
they are uint32_t, uint8_t, int16_t  etc


                ^^
Ha! Another example of redundancy that just annoys the hell out of me.
Why does a _type_ need a "_t" suffix? As if someone would use a variable
or make a function called "uint32".  Arrgh!

Yeah, backwards compatibility and all, and they had to choose as ugly
name as possible so that the least possible amount of people would have
trouble porting their code to C99, all right...

:-), and good night,

-Antti
Aug 28 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
[me confused, but biting anyway]


I wouldn't mind standardizing on some names like sint8, sint16, uint32,
uint64, because 90% of all projects have those kind of typedefs.


C99 already standardized this why invent different names?
they are uint32_t, uint8_t, int16_t  etc


                 ^^
 Ha! Another example of redundancy that just annoys the hell out of me.
 Why does a _type_ need a "_t" suffix? As if someone would use a variable
 or make a function called "uint32".  Arrgh!


I agree completely. Who suggested the _t for D? (I do hope it wasn't me!!)
Aug 28 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
[snip]


 I am not at all of the opinion that we should drop Exception and Error
 from those names where they naturally belong. In fact, this inheritance
 hierarchy would be a perfect example of using names Exception and Error
 precisely where they fit well and not using them where they don't:

 (Forgive me for switching the places of OutOfMemory and
 VirtualMemoryError -- I believe the hypothetical hierarchy looks more
 realistic this way)


nw


 class SystemError : Error

 class Win32Error : SystemError

 class VirtualMemoryError : Win32Error

 class OutOfMemory : VirtualMemoryError


Why is this intrinsically an exception? It could be a member of an error
code enumeration ...


 class GeneralProtectionFault : VirtualMemoryError


Why is this intrinsically an exception? ... as could this ...


 class IllegalOperation : VirtualMemoryError


Why is this intrinsically an exception? ... and this

None of these three are convincing, and to be honest without an explicit
agreement (and widely adopted programmer mindset) that exceptions is *the*
default error handling context/mechanism/paradigm of D it can be argued that
no descriptive could be only, and unambiguously, applied to an exception.

[Of course, that argument taken to its ultimate limits will have C in front
of all classes, E in front of all enums, etc. etc., so we need to be aware
that we are proposing a special case for exceptions. I believe for
exceptions a special case is warranted, and it seems that so does just about
every other poster so far, the divergent views are on how special.]


 I agree that the non-leaf nodes of the inheritance hierarchy tend to
 describe errors of a general domain, and the proper name for them is
 "area" + "Exception"/"Error".

 But the leaf nodes often mean just one particular error condition, in
 which case it has a name that already indicates what kind of a creature
 it is. IndexOutOfBounds? An exception. StackOverflow? An error.


Could be return codes; enum values; flags passed as arguments to a
validation engine to stipulate what conditions to simulate; classes in a
parser for Python (or whatever language) you wish to implement in D.


 ObjectFactoryBuilder? Uh, neither. But that's obvious. And so on.
 Besides, there wouldn't be a lot of them, not at least in the standard
 library, at least if it wouldn't grow too bloated. You could probably
 memorize them if you wanted.

 And no one said that XXXException wouldn't be a valid leaf exception
 class -- certainly it is if there is no better name.
 AuthenticationException, for example, is a perfectly good name for a
 class if you don't know the particular reason (or don't care about
 differentiating them) for an exception that an authentication module
 just throwed.

 The fundamental point is: I would prefer catching DivisionByZero instead
 of DivisionByZeroException and StackOverflow instead of
 StackOverflowError, because in these particular cases stating the
 obvious -- that we're talking about an exception or an error -- seems
 just too redundant. It feels as if you named application's main function
 mainFunction() instead of main() or its arguments (String[]
 argumentStrings) instead of (String[] args). Or used the horrid
 CSomeClass prefix or any sort of hungarian notation.


This is a common misunderstanding of the origin of the "C" prefix. It was
not to prescribe a style to which everyone should adhere, it was to
disambiguate Microsoft's classes from those of programmers and third-party
libraries, and exactly corresponds in intent to the use of T in Borland's
code.

However, nearly everyone who programs in MFC and/or ATL thinks that that is
what they should be doing, hence the utter fatuous nature of what it has
become. The fact that Visual Studio tools have always made it very hard to
have classes that _do not_ begin with C only adds to the stupidity.

As for hungarian, again that is a perversion of an idea with some merit.

 I kind of like some hungarian if it tells me what something does, but I
don't care to know what it is, since its type may well be changing during
maintenance and the last thing I want is to be lied to by the code. That's
what managers are for.

- bXyz tells me that something is boolean. The fact that it may be bool,
int, or unsigned long is immaterial. The b tells me it will logically
represent a boolean quantity. That is useful and portable (except where some
egregious toad may start using a boolean variable to hold a set of bit
flags, or an integral range, at which point he will be 10th-floored!)

- lXyz tells me that something is a long. Not only do I not care, but as
soon as it is changed to an int it is a self-documenting lie!

- using p for a pointer is still nice for many things, but is ill-at-ease
with generic (template) algorithms, so is dying out.

But I shall not go on, because this is a holy war and no-one is going to
move one iota, so let's forget I said anything about hungarian. It's dying
out, which is good for the most part. The few good things in it are not good
enough to keep it around compared to the scope of badness that can be gotten
rid of.


 (Which is, of course, a matter of personal opinion.)

 But I agree that maybe, just maybe, a little extra typing would be
 better than having to think whether to put in the extra Exception or
 not. Consistency tends to be a good thing. After all, I'm programming in
 a statically typed language where you need to keep stating the obvious,
 and I even consider that a good thing. Besides, most IDEs and editors
 have auto-completion for us lazy typers...


That's exactly the point. Picking figures out of the air, it may be that 60%
of exception/error types should have the postfix, 20% could unambiguously
not have it, and 20% would be argued about at length, to the complete waste
of everyone's time.

Quite frankly I hate adorning my classes with anything - prefix or postfix -
but I believe in consistency and clarity more than adherence to any styling
convention (whether my own or that of any frameworks). So I think
SomeBadThingException is over-egging the pudding, but it is worth it
because:

 - it is automatable
 - it is consistent
 - it is immediately clear
 - it is clear to people whose first language is not English, or who may not
immediately grok that SomeBadThing is inherently an error


  1. Your tool will have to be pretty smart to deduce up four levels that
 VirtualMemory is an Error. Most people do, and will continue to do, use
 grep.


 This is a stunningly valid argument.


Quite. :)


 Even though I think that non-leaf exception classes should mostly be
 called XXXError or YYYException, and so the leaf nodes would have to
 derive from a class that has one of those endings, and therefore
 "grep -B1 Error *.d" would indeed find most if not all of them. But this
 would not be 100% bullet-proof, firstly because you really don't *have*
 to specify the base class in the same or the next line to make it
 compile, secondly because that switch works only in GNU grep, and
 thirdly because 90% of people would not bother to use or learn that
 switch, let alone have an opportunity to use a more sophisticated source
 browsing system.

 How often do you want to grep for all exceptions? (It's been ages since
 I've used them in a real project; lately I've been working with systems
 that don't support exceptions, so I don't really remember what to answer
 myself.)


Generally not often, but enough to want to be able to do so easily. In fact
an article I have coming out in next month's CUJ comparing certain syntactic
and semantic aspects of a variety of languages nearly had the statement that
D simple crashes on using null references because I could not locate the
error/exception that is thrown on the access violation!

Short answer: often enough!
Aug 28 2003
prev sibling next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
----- Original Message -----
From: "Matthew Wilson" <matthew stlsoft.org>
Newsgroups: D
Sent: Wednesday, August 20, 2003 4:00 AM
Subject: Exception naming conventions - Phobos, and third party libraries



 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


Hi,

    I vote for suffixes. It's the way Java does things, so we have a fair
share of programmers familiar with this convention. Personally I don't like
this kind of name decoration, I prefer plain names without this apendix.
Calling something AbnormalConditionsMetException is redundant IMO.

    Best regards,
    Daniel Yokomiso.

"I have great faith in fools - my friends call it self-confidence."
 - Edgar Allen Poe


---
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: 19/8/2003
Aug 24 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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?


I don't know what's the right move here. The only thing I'm sure about is
that DbC contract violations, array bounds errors, access violations, switch
default exceptions, should share a common ancestor, perhaps called
FatalException or FatalError. Generally, one should be very careful about
catching these, as they mean that the program is likely corrupted and cannot
continue.
Sep 01 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 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?


 I don't know what's the right move here. The only thing I'm sure about is
 that DbC contract violations, array bounds errors, access violations,


switch

 default exceptions, should share a common ancestor, perhaps called
 FatalException or FatalError. Generally, one should be very careful about
 catching these, as they mean that the program is likely corrupted and


cannot

 continue.


Well, I'm not one for blatant plagiarism (a subtler kind, maybe ;-) ), but I
think maybe we should bite the bullet and have an interface Throwable.
Provided within this are two classes Error and Exception, with the obvious
implications. I think the language should enforce that throw statements can
only throw something derived from throwable (for all that I hate hierarchies
and polymorphic types as a rule, I believe they are perfectly at home in
exception-handling, and preferable to any other types), and should warn (or
maybe spit) if anyone tries to derive directly from Throwable.

Then we bite the other bullet and decree that all exception classes, without
exception, end in Exception. Similarly all Error classes, on pain of error,
end in Error. It may be hateful, but it's less hateful than all the
alternatives. On the surface of software-engineering excellence D should aim
to be a local maxima, since anything else is futile.

In regards to your qualm about catching errors, it would be possible to
define Throwable in the following way:

interface Throwable
{
  bool IsContinuable();
}

to which Errors would reply false. I've just thought of this off the top of
my head, so there may be some fundamental flaw to the idea, but maybe it
could work?

Finally, I also think that the default actions for the various built-in
responses that you mention (and others no doubt) should be as you say, but
there should be a simple hookable mechanism, on a per-thread and/or
per-process basis, whereby one can override these responses. I know I'd
rather have an abort() than an exception when I have contract violations,
for example, but others take a contrary view.


btw, is there a "finally" in D?

-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac

mailto:matthew stlsoft.org
http://www.stlsoft.org
news://news.digitalmars.com/c++.stlsoft

"I can't sleep nights till I found out who hurled what ball through what
apparatus" -- Dr Niles Crane

----------------------------------------------------------------------------
---
Sep 01 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj1dut$12ms$1 digitaldaemon.com...

 I don't know what's the right move here. The only thing I'm sure about




is

 that DbC contract violations, array bounds errors, access violations,


 switch

 default exceptions, should share a common ancestor, perhaps called
 FatalException or FatalError. Generally, one should be very careful




about

 catching these, as they mean that the program is likely corrupted and


 cannot

 continue.


 Well, I'm not one for blatant plagiarism (a subtler kind, maybe ;-) ), but


I

 think maybe we should bite the bullet and have an interface Throwable.
 Provided within this are two classes Error and Exception, with the obvious
 implications. I think the language should enforce that throw statements


can

 only throw something derived from throwable (for all that I hate


hierarchies

 and polymorphic types as a rule, I believe they are perfectly at home in
 exception-handling, and preferable to any other types), and should warn


(or

 maybe spit) if anyone tries to derive directly from Throwable.


Since any Object can be thrown and caught, I don't see the point of having a
Throwable be the root of them. It just seems redundant.


 Then we bite the other bullet and decree that all exception classes,


without

 exception, end in Exception. Similarly all Error classes, on pain of


error,

 end in Error. It may be hateful, but it's less hateful than all the
 alternatives. On the surface of software-engineering excellence D should


aim

 to be a local maxima, since anything else is futile.

 In regards to your qualm about catching errors, it would be possible to
 define Throwable in the following way:

 interface Throwable
 {
   bool IsContinuable();
 }

 to which Errors would reply false. I've just thought of this off the top


of

 my head, so there may be some fundamental flaw to the idea, but maybe it
 could work?


If all Errors would reply false, and all Exceptions true, then this is
equivalent to: cast(Exception)(o), though perhaps a little prettier!


 Finally, I also think that the default actions for the various built-in
 responses that you mention (and others no doubt) should be as you say, but
 there should be a simple hookable mechanism, on a per-thread and/or
 per-process basis, whereby one can override these responses. I know I'd
 rather have an abort() than an exception when I have contract violations,
 for example, but others take a contrary view.


We've both seen some pretty adamant advocacy for this, and I'm half
convinced. But not totally yet <g>.


 btw, is there a "finally" in D?


Yes. try-catch-finally.
Sep 02 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bj2ii9$2nu3$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj1dut$12ms$1 digitaldaemon.com...

 I don't know what's the right move here. The only thing I'm sure about




 is

 that DbC contract violations, array bounds errors, access violations,


 switch

 default exceptions, should share a common ancestor, perhaps called
 FatalException or FatalError. Generally, one should be very careful




 about

 catching these, as they mean that the program is likely corrupted and


 cannot

 continue.


 Well, I'm not one for blatant plagiarism (a subtler kind, maybe ;-) ),




but

 I

 think maybe we should bite the bullet and have an interface Throwable.
 Provided within this are two classes Error and Exception, with the




obvious

 implications. I think the language should enforce that throw statements


 can

 only throw something derived from throwable (for all that I hate


 hierarchies

 and polymorphic types as a rule, I believe they are perfectly at home in
 exception-handling, and preferable to any other types), and should warn


 (or

 maybe spit) if anyone tries to derive directly from Throwable.


 Since any Object can be thrown and caught, I don't see the point of having


a

 Throwable be the root of them. It just seems redundant.


Well, I don't think any object should be able to be thrown. Other than the
fact that all objects have some basic commonality, it. toString(), what's
the difference between that and the evil C++ throw int(1); ?


 Then we bite the other bullet and decree that all exception classes,


 without

 exception, end in Exception. Similarly all Error classes, on pain of


 error,

 end in Error. It may be hateful, but it's less hateful than all the
 alternatives. On the surface of software-engineering excellence D should


 aim

 to be a local maxima, since anything else is futile.

 In regards to your qualm about catching errors, it would be possible to
 define Throwable in the following way:

 interface Throwable
 {
   bool IsContinuable();
 }

 to which Errors would reply false. I've just thought of this off the top


 of

 my head, so there may be some fundamental flaw to the idea, but maybe it
 could work?


 If all Errors would reply false, and all Exceptions true, then this is
 equivalent to: cast(Exception)(o), though perhaps a little prettier!


Prettier, and handles cases none of us have yet thought of.

However, thinking about it, maybe Throwable should be an abstract class.
That way, we could add methods (with default implementations) for new
features in the future without breaking code. Dunno; just tossing it out
there.


 Finally, I also think that the default actions for the various built-in
 responses that you mention (and others no doubt) should be as you say,




but

 there should be a simple hookable mechanism, on a per-thread and/or
 per-process basis, whereby one can override these responses. I know I'd
 rather have an abort() than an exception when I have contract




violations,

 for example, but others take a contrary view.


 We've both seen some pretty adamant advocacy for this, and I'm half
 convinced. But not totally yet <g>.


Neither am I, for either case. That's why I'm suggesting the pragmatic
approach of having it overrideable. Not like me, eh? ;)


 btw, is there a "finally" in D?


 Yes. try-catch-finally.


gotcha
Sep 02 2003