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

 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,


 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.

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


 class)

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

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


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


the moment, and it would be nice not to have to go back and change all


names down the track.

Walter, can you make your feelings clear at this point, as this may help


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

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

 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舐i" <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


 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

     {
         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舐i" <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


 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


 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


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


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


 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

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

 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


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


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


 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

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

 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



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



 words "Error" or "Exception".

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


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


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


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


 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

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

 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

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

 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

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

 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

 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


 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


 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

 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舐i" <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




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



 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

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

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

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

 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

 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

 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


 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


 can get an overall agreement, because I'm writing some exceptional code


 the moment, and it would be nice not to have to go back and change all


 names down the track.

 Walter, can you make your feelings clear at this point, as this may help

 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,

 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

 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


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

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


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

 continue.

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

 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

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

 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

 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,

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

 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

 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

 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


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

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


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

 continue.

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


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


 implications. I think the language should enforce that throw statements

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

 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

 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

 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,

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

 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

 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

 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,


 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


 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