"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

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

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

"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.

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

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

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

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

----- 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

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