[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

[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!!)

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

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

I don't know what's the right move here. The only thing I'm sure about is that DbC contract violations, array bounds errors, access violations, switch default exceptions, should share a common ancestor, perhaps called FatalException or FatalError. Generally, one should be very careful about catching these, as they mean that the program is likely corrupted and cannot continue.

> > I'd just like to, if we can, get a consensus on the naming conventions
for
> > exceptions. Here're two to conjure with:
> >
> > 1. Trailing type word
> >
> >     Errors are called TerminalThingError
> >     Exceptions are called SurprisingThingException
> >
> > 2. Prefix
> >
> >     Errors are called ETerminalThing
> >     Exceptions are called XSurprisingThing
> >
> > Frankly, I'm not really bothered which we go for, but I want to see if
we
> > can get an overall agreement, because I'm writing some exceptional code
at
> > the moment, and it would be nice not to have to go back and change all
the
> > names down the track.
> >
> > Walter, can you make your feelings clear at this point, as this may help
> us
> > all save a lot of hot air in debating options that you're going to veto?
>
> I don't know what's the right move here. The only thing I'm sure about is that DbC contract violations, array bounds errors, access violations,
switch
> default exceptions, should share a common ancestor, perhaps called FatalException or FatalError. Generally, one should be very careful about catching these, as they mean that the program is likely corrupted and
cannot
> continue.

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

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

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

interface Throwable
{
  bool IsContinuable();
}

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

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


btw, is there a "finally" in D?

-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac

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

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

----------------------------------------------------------------------------
---

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bj1dut$12ms$1@digitaldaemon.com...
> > I don't know what's the right move here. The only thing I'm sure about
is
> > that DbC contract violations, array bounds errors, access violations,
> switch
> > default exceptions, should share a common ancestor, perhaps called FatalException or FatalError. Generally, one should be very careful
about
> > catching these, as they mean that the program is likely corrupted and
> cannot
> > continue.
>
> Well, I'm not one for blatant plagiarism (a subtler kind, maybe ;-) ), but
I
> think maybe we should bite the bullet and have an interface Throwable. Provided within this are two classes Error and Exception, with the obvious implications. I think the language should enforce that throw statements
can
> only throw something derived from throwable (for all that I hate
hierarchies
> and polymorphic types as a rule, I believe they are perfectly at home in exception-handling, and preferable to any other types), and should warn
(or
> maybe spit) if anyone tries to derive directly from Throwable.

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

> Then we bite the other bullet and decree that all exception classes,
without
> exception, end in Exception. Similarly all Error classes, on pain of
error,
> end in Error. It may be hateful, but it's less hateful than all the alternatives. On the surface of software-engineering excellence D should
aim
> to be a local maxima, since anything else is futile.
>
> In regards to your qualm about catching errors, it would be possible to define Throwable in the following way:
>
> interface Throwable
> {
>   bool IsContinuable();
> }
>
> to which Errors would reply false. I've just thought of this off the top
of
> my head, so there may be some fundamental flaw to the idea, but maybe it could work?

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

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

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

> btw, is there a "finally" in D?

Yes. try-catch-finally.

"Walter" <walter@digitalmars.com> wrote in message news:bj2ii9$2nu3$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bj1dut$12ms$1@digitaldaemon.com...
> > > I don't know what's the right move here. The only thing I'm sure about
> is
> > > that DbC contract violations, array bounds errors, access violations,
> > switch
> > > default exceptions, should share a common ancestor, perhaps called FatalException or FatalError. Generally, one should be very careful
> about
> > > catching these, as they mean that the program is likely corrupted and
> > cannot
> > > continue.
> >
> > Well, I'm not one for blatant plagiarism (a subtler kind, maybe ;-) ),
but
> I
> > think maybe we should bite the bullet and have an interface Throwable. Provided within this are two classes Error and Exception, with the
obvious
> > implications. I think the language should enforce that throw statements
> can
> > only throw something derived from throwable (for all that I hate
> hierarchies
> > and polymorphic types as a rule, I believe they are perfectly at home in exception-handling, and preferable to any other types), and should warn
> (or
> > maybe spit) if anyone tries to derive directly from Throwable.
>
> Since any Object can be thrown and caught, I don't see the point of having
a
> Throwable be the root of them. It just seems redundant.

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

> > Then we bite the other bullet and decree that all exception classes,
> without
> > exception, end in Exception. Similarly all Error classes, on pain of
> error,
> > end in Error. It may be hateful, but it's less hateful than all the alternatives. On the surface of software-engineering excellence D should
> aim
> > to be a local maxima, since anything else is futile.
> >
> > In regards to your qualm about catching errors, it would be possible to define Throwable in the following way:
> >
> > interface Throwable
> > {
> >   bool IsContinuable();
> > }
> >
> > to which Errors would reply false. I've just thought of this off the top
> of
> > my head, so there may be some fundamental flaw to the idea, but maybe it could work?
>
> If all Errors would reply false, and all Exceptions true, then this is
> equivalent to: cast(Exception)(o), though perhaps a little prettier!

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

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

> > Finally, I also think that the default actions for the various built-in responses that you mention (and others no doubt) should be as you say,
but
> > there should be a simple hookable mechanism, on a per-thread and/or per-process basis, whereby one can override these responses. I know I'd rather have an abort() than an exception when I have contract
violations,
> > for example, but others take a contrary view.
>
> We've both seen some pretty adamant advocacy for this, and I'm half convinced. But not totally yet <g>.

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

> > btw, is there a "finally" in D?
>
> Yes. try-catch-finally.

gotcha