www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - exception inheritance proposal

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
Over the past few days/weeks I've been going over the phobos exception 
usage. Below is my proposal for modifying the phobos exception class 
inheritance hierarchy (indenting indicates subclassing). I have no idea if 
Walter would actually accept anything close to this proposal, but I figure 
what the heck. See notes and questions at the end, too.

Object
   OutOfMemory
   AssertionFailure (was AssertError:Error)
      NoSwitchDefault (was SwitchError:Error)
   Exception
      ParamException (new)
         ParamNullException (new)
         ParamRangeException (new)
      IndexException (new)
         ArrayBoundsException (was ArrayBoundsError:Error)
      CollectionCopyException (new)
         ArrayCopyException (was Error in internal/arraycat.d)
      NotSupportedException (new)
      NotImplementedException (new)
      AddressException
      Base64Exception
         Base64CharException
      CastException (new)
         ArrayCastException (was Error in internal/arraycast.d)
      ConvException (was ConvError:Error)
         ConvOverflowException (was ConvOverflowError:ConvError)
      DateParseException (was DateParseError:Error)
      SystemError (see Regan's code posted on thread about std.syserror)
         FileException (was FileException:Exception)
         SocketException (was SocketException:Exception)
            SocketAcceptException
         HostException (was HostException:Exception)
         RegistryException (was RegistryException:Win32Exception)
         ExeModuleException (was ExeModuleException:Exception)
      FormatException (was FormatError:Error)
      ModuleCtorException (was ModuleCtorError:Exception)
      OpenRJException
         DatabaseException
         InvalidKeyException
         InvalidTypeException
      RegExpException (was RegExpError:Error)
      StreamException
         ReadException
         WriteException
         SeekException
         StreamFileException
            OpenException
      StringException
      ThreadException (was ThreadError:Error)
         OutOfThreadsException (new)
      URIException (was URIError:Error)
      UTFException (was UtfError:Error)
      ZipException
      ZlibException

Notes:
1. removed std.windows.registry.Win32Exception since it overlaps with
     SystemError for Windows
2. remove FooError aliases for std.stream exceptions
3. some exceptions might be thrown with SystemError causes
     (eg StreamFileException, ThreadException)
4. RegistryException is thrown once without a system error code
5. NotSupportedException will be a cause in
     - std.mmfile some thrown FileExceptions
     - std.stream in a StreamException that replaces a raw Exception
     - std.zip in several ZipExceptions
6. Backwards incompatibilities are limited (hopefully) to class names 
involving Error
   and subclassing Error. The subclassing Error switches to Exception except
   for asserts and switch defaults don't subclass Exception in the new 
scheme.
7. The array errors now subclass general reusable errors.

Exception is defined as
class Exception {
    char[] msg;
    Object cause; // new

    this(char[] msg, Object cause = null) { // new
        this.msg = msg;
        this.cause = cause; // new
    }

    void print() {
        printf("%.*s\n", msg);
        if (cause) cause.print(); // new
    }

    char[] toString() { return msg; }
}

For the definition of SystemError see Regan's post 
digitalmars.D/21282

Questions:
1. what should the top few lines of the hierarchy look like?
2. should modules that currently reuse one exception create subclasses?
3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
     throw a raw Exception)
4. what is missing? 
Apr 13 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I don't much care about the leaf-side hierarchy, as I think the root 
is far more important. I'm a bit surprised to see that you've stuck 
with Object as the common base of the hierarchy. What is the reason 
behind that, given that the impression from the recent discussions 
has been, IME, that most wanted a change?

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d3kkph$2t76$1 digitaldaemon.com...
 Over the past few days/weeks I've been going over the phobos 
 exception usage. Below is my proposal for modifying the phobos 
 exception class inheritance hierarchy (indenting indicates 
 subclassing). I have no idea if Walter would actually accept 
 anything close to this proposal, but I figure what the heck. See 
 notes and questions at the end, too.

 Object
   OutOfMemory
   AssertionFailure (was AssertError:Error)
      NoSwitchDefault (was SwitchError:Error)
   Exception
      ParamException (new)
         ParamNullException (new)
         ParamRangeException (new)
      IndexException (new)
         ArrayBoundsException (was ArrayBoundsError:Error)
      CollectionCopyException (new)
         ArrayCopyException (was Error in internal/arraycat.d)
      NotSupportedException (new)
      NotImplementedException (new)
      AddressException
      Base64Exception
         Base64CharException
      CastException (new)
         ArrayCastException (was Error in internal/arraycast.d)
      ConvException (was ConvError:Error)
         ConvOverflowException (was ConvOverflowError:ConvError)
      DateParseException (was DateParseError:Error)
      SystemError (see Regan's code posted on thread about 
 std.syserror)
         FileException (was FileException:Exception)
         SocketException (was SocketException:Exception)
            SocketAcceptException
         HostException (was HostException:Exception)
         RegistryException (was RegistryException:Win32Exception)
         ExeModuleException (was ExeModuleException:Exception)
      FormatException (was FormatError:Error)
      ModuleCtorException (was ModuleCtorError:Exception)
      OpenRJException
         DatabaseException
         InvalidKeyException
         InvalidTypeException
      RegExpException (was RegExpError:Error)
      StreamException
         ReadException
         WriteException
         SeekException
         StreamFileException
            OpenException
      StringException
      ThreadException (was ThreadError:Error)
         OutOfThreadsException (new)
      URIException (was URIError:Error)
      UTFException (was UtfError:Error)
      ZipException
      ZlibException

 Notes:
 1. removed std.windows.registry.Win32Exception since it overlaps 
 with
     SystemError for Windows
 2. remove FooError aliases for std.stream exceptions
 3. some exceptions might be thrown with SystemError causes
     (eg StreamFileException, ThreadException)
 4. RegistryException is thrown once without a system error code
 5. NotSupportedException will be a cause in
     - std.mmfile some thrown FileExceptions
     - std.stream in a StreamException that replaces a raw 
 Exception
     - std.zip in several ZipExceptions
 6. Backwards incompatibilities are limited (hopefully) to class 
 names involving Error
   and subclassing Error. The subclassing Error switches to 
 Exception except
   for asserts and switch defaults don't subclass Exception in the 
 new scheme.
 7. The array errors now subclass general reusable errors.

 Exception is defined as
 class Exception {
    char[] msg;
    Object cause; // new

    this(char[] msg, Object cause = null) { // new
        this.msg = msg;
        this.cause = cause; // new
    }

    void print() {
        printf("%.*s\n", msg);
        if (cause) cause.print(); // new
    }

    char[] toString() { return msg; }
 }

 For the definition of SystemError see Regan's post 
 digitalmars.D/21282

 Questions:
 1. what should the top few lines of the hierarchy look like?
 2. should modules that currently reuse one exception create 
 subclasses?
 3. when is it ok to just throw Exception? (ie - should 
 internal/gc/gc.d
     throw a raw Exception)
 4. what is missing?
 

Apr 13 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d3kos2$2vnh$1 digitaldaemon.com...
I don't much care about the leaf-side hierarchy, as I think the root is far 
more important. I'm a bit surprised to see that you've stuck with Object as 
the common base of the hierarchy. What is the reason behind that, given 
that the impression from the recent discussions has been, IME, that most 
wanted a change?

Technically Object will always be the root as long as 'throw' can take Object. I should have put at the top of the post that I assume the language stays the same - if Walter changes what gets thrown then the root will change. I have no idea what Walter thinks of changing the root. So I proceeded given Object is the root, what should the next few branches be? I argue the depth of the tree should be kept as small as practical so that we don't end up with the random hierarchy like the current phobos and Java (ie - fewer decisions for class writers means fewer mistakes). The key is that the tree we have still needs to be useful and flexible. I see Object and Exception have enough exception-friendly features except for stack traces and perhaps other unknown features. If stack traces ever get introduced to D we could wedge in another branch of the tree but personally I'd prefer to do it though an interface implemented by Exception and (for argument's sake I'll assume my proposal) AssertionFailure (OutOfMemory makes me nervous wrt stack traces for reasons I posted in another thread: where does the memory for the stack trace come from?). That would keep the tree depth down while adding flexibility. Other features could be added to Exception and/or through interfaces. -Ben ps - what does IME mean?
Apr 13 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d3ksf2$1vm$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d3kos2$2vnh$1 digitaldaemon.com...
I don't much care about the leaf-side hierarchy, as I think the 
root is far more important. I'm a bit surprised to see that you've 
stuck with Object as the common base of the hierarchy. What is the 
reason behind that, given that the impression from the recent 
discussions has been, IME, that most wanted a change?

Technically Object will always be the root as long as 'throw' can take Object. I should have put at the top of the post that I assume the language stays the same - if Walter changes what gets thrown then the root will change. I have no idea what Walter thinks of changing the root. So I proceeded given Object is the root, what should the next few branches be? I argue the depth of the tree should be kept as small as practical so that we don't end up with the random hierarchy like the current phobos and Java (ie - fewer decisions for class writers means fewer mistakes). The key is that the tree we have still needs to be useful and flexible. I see Object and Exception have enough exception-friendly features except for stack traces and perhaps other unknown features. If stack traces ever get introduced to D we could wedge in another branch of the tree but personally I'd prefer to do it though an interface implemented by Exception and (for argument's sake I'll assume my proposal) AssertionFailure (OutOfMemory makes me nervous wrt stack traces for reasons I posted in another thread: where does the memory for the stack trace come from?). That would keep the tree depth down while adding flexibility. Other features could be added to Exception and/or through interfaces.

Ok. Makes sense. (Man, I need to get my paranoia gland sorted!! <g>)
 ps - what does IME mean?

In my estimation.
Apr 13 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 13 Apr 2005 22:33:19 -0400, Ben Hinkle <ben.hinkle gmail.com>  
wrote:

<snip>

Looks good.

My first thought is that "SystemError" is the only one with "Error" in  
it's name. I think it's the most accurate description of what it is but it  
seemed odd that it was the only one. Thoughts?

 Questions:
 1. what should the top few lines of the hierarchy look like?

These ones?
 Object
   OutOfMemory
   AssertionFailure (was AssertError:Error)
      NoSwitchDefault (was SwitchError:Error)

they look good to me.
 2. should modules that currently reuse one exception create subclasses?

Example? I have some vague idea of what you mean but I'd prefer to comment on something concrete.
 3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
      throw a raw Exception)

My first thought is no, I say that because "Exception" doesn't tell me what went wrong, it just says something went wrong. What is the reason gc throws it? Shouldn't that be the name of the exception it throws?
 4. what is missing?

Nothing I can think of at this time. Regan
Apr 14 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 2. should modules that currently reuse one exception create subclasses?

Example? I have some vague idea of what you mean but I'd prefer to comment on something concrete.

std.format is one I had in mind. It reuses FormatError (aka FormatException) for all error conditions and I wonder if user code will want to catch and handle particular failures (eg invalid specifier, int overflow, the infamous formatArg, etc). Currently if they want to react differently to those situations the code would have to inspect the message string which is fragile. There are probably other modules with similar generous exception reuse.
 3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
      throw a raw Exception)

My first thought is no, I say that because "Exception" doesn't tell me what went wrong, it just says something went wrong. What is the reason gc throws it? Shouldn't that be the name of the exception it throws?

internal/gc/gc.d currently throws Error("incompatible gc versions") in setGCHandle which is used to sync up dynamically loaded libraries. I thought of adding GCException:Exception and GCVersionException:GCException but then that seemed like overkill. One would think the code loading and syncing up a dynamically loaded lib wouldn't want to treat GC errors differently from whatever else that action can throw. I'm still not sure. Another example that I decided in the other direction was the array casting errors in internal/arraycast. That module throws raw Errors and I figured a subclass of a general CastException would be useful to throw in an opCast for a struct or class. So that one I added to the hierarchy.
Apr 14 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Apr 2005 07:59:07 -0400, Ben Hinkle <ben.hinkle gmail.com>  
wrote:
 2. should modules that currently reuse one exception create subclasses?

Example? I have some vague idea of what you mean but I'd prefer to comment on something concrete.

std.format is one I had in mind. It reuses FormatError (aka FormatException) for all error conditions and I wonder if user code will want to catch and handle particular failures

That was my thought also. If you wanted to "catch and handle particular failures" you'd need some way to distinguish them.
 (eg invalid specifier, int overflow, the infamous
 formatArg, etc). Currently if they want to react differently to those
 situations the code would have to inspect the message string which is
 fragile.

So, the question is "Do we need to catch and handle particular failures in this case?" My answer, no idea sorry.
 There are probably other modules with similar generous exception
 reuse.

Indeed. What do you think the pros/cons of subclassing vs throwing <exception_name> with a differing 'cause' are in these sorts of cases?
 3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
      throw a raw Exception)

My first thought is no, I say that because "Exception" doesn't tell me what went wrong, it just says something went wrong. What is the reason gc throws it? Shouldn't that be the name of the exception it throws?

internal/gc/gc.d currently throws Error("incompatible gc versions") in setGCHandle which is used to sync up dynamically loaded libraries. I thought of adding GCException:Exception and GCVersionException:GCException but then that seemed like overkill. One would think the code loading and syncing up a dynamically loaded lib wouldn't want to treat GC errors differently from whatever else that action can throw. I'm still not sure.

What other errors can arise? FileNotFound, PermissionDenied, GCVersionException? i.e. might you want to catch FileNotFound and give the user a chance to find the dll for you?
 Another example that I decided in the other direction was the array  
 casting
 errors in internal/arraycast. That module throws raw Errors and I  
 figured a
 subclass of a general CastException would be useful to throw in an opCast
 for a struct or class. So that one I added to the hierarchy.

Makes sense. Regan
Apr 14 2005
prev sibling parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
Comments:
1. Assertion Failure and sub-classes should have stack tracing. Should they
then have a common ancestor with Exceptions? (see my post in other thread).
It would be cleaner if all stack-traced object inherited through the same
base object, but the functionality can be imported by other means.
2. As others have said, I would definitely rename SystemError to
SystemException (deprecating the old name for a while perhaps). It is really
a sore thumb...
3. I would trim on the numbers of exceptions. Examples:
#1: ParamException is enough, I don't think ParamNullException and
ParamRangeException are needed. Less exceptions means more consistency
overall in D programs. ParamException means the client code screwed up.
Stack trace should tell you where.
#2: ArrayCopyException... same thing: parent class is enough.
#3: Difference between NotSupportedException and NotImplementedException?
Conceptually, I undersand there is a difference. In practice though, it
means you called code that does nothing. I wouldeliminate one of the two.
#4: Base64CharException: parent is enough
#5: Shouldn't DateParseException be a ParamException?
#6: ArrayCastException: parent is enough
#7: What do StringException, ThreadException, ZipException and ZlibException
mean in practice? It tells us *where* the exception occured, not *what*
occured. The exception name should refer to what occured. For instance, if
Zlib failed because a file was not found, a FileOpenException should be
sent.

Honestly, before we reinvent the wheel, I believe we should take a long hard
look at own C# and Java define their exception hierarchy and mimic it as
much as possible. These languages have been in the field for some time and
some thought went into their exceptions hierarchy design. I would leverage
this thought process as much as possible.

The reason I'm saying that is that somehow this hierarchy seems contrived...
It seems to stem from a desire to map what is currently there to something a
little better (which would in itself be a *very* good thing, don't get me
wrong). However, I believe a more in-depth redesign would be more
profitable.

***
Walter, Ben, and all,

Taking a step back, I see in this community people actively participating,
obviously willing to improve the language and make things better. This is
extremely valuable. Why not use these resources and this talent in a more...
productive manner? Maybe I have been away from newgroup for too long, but
all these posts back and forth hardly seem productive to me. What seems to
be going on is endless debates about points of detail, while overall not
much is achieved. Don't get me wrong, debating is good. As long as it leads
somewhere... I have proposed to spend time investigating stack tracing. You
Ben are intend on redesigning the exception hierarchy. I am sure other
people would like to contribute in various other ways.

Why doesn't Walter "elect" some people to make high level design proposals
on chosen topics?  I'm sure that over the years he's come to recognize
individuals who have made a sizeable contribution to D (like you Ben).
The idea would be to channel all our ideas to one person responsible for
drafting a high level design about a specific topic (subject expert). Walter
would later appose his seal (or not) on that document and implementation
could begin, by Walter himself or by a designated individual(s). Walter
would have the last word: if he believes the document does not adequately
covers possible design alternatives and/or that the suggested amendment is
inappropriate, he could veto it (at a political price, of course... ;)

The workload would be shared between Walter and the community and I am sure
we would all reap the benefits quite rapidly. That is how open source
projects work anyway, no? Walter would be the big Kauna and he would have a
few lieutenants working for him. I know I'm not proposing anything new. It
just appears to me that even at this point, Walter probably can't cope with
all the threads, all the suggestions, all the bugs, etc.

Anyway, the bottom line for me I guess is that I'm willing to make a
contribution to D if I can because I believe it has a lot of potential.
However, I have no time to spend in newsgroup debating endlessly. I suppose
it is probably the same for the most interesting elements in this community.
I'm available, use me or lose me!  ;)

No kidding, even writing this, I'm afraid I'm losing my time. What if
Walter's idea is that the exception hierarchy is 100% fine as it is? What
impact do we have? On the other hand, if Walter elected you Ben as subject
expert on this matter, well, I'd spend 5 times as much time as I spent
writing this, making research on my own and proposing amendments a lot more
tangible than "super-class is enough". I'd give alternatives, examples, etc.
to make my point and try to convince you because in the end you would be
writing the official proposal. We all know that consensus is something
unachievable, so there must be one person to receive all comments on a given
subject and weighs alternatives. As it stands, who's responsible for making
a decision? At this stage, the D community lives on hope...

So, Walter, what say you?

Max



"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3kkph$2t76$1 digitaldaemon.com...
 Over the past few days/weeks I've been going over the phobos exception
 usage. Below is my proposal for modifying the phobos exception class
 inheritance hierarchy (indenting indicates subclassing). I have no idea if
 Walter would actually accept anything close to this proposal, but I figure
 what the heck. See notes and questions at the end, too.

 Object
    OutOfMemory
    AssertionFailure (was AssertError:Error)
       NoSwitchDefault (was SwitchError:Error)
    Exception
       ParamException (new)
          ParamNullException (new)
          ParamRangeException (new)
       IndexException (new)
          ArrayBoundsException (was ArrayBoundsError:Error)
       CollectionCopyException (new)
          ArrayCopyException (was Error in internal/arraycat.d)
       NotSupportedException (new)
       NotImplementedException (new)
       AddressException
       Base64Exception
          Base64CharException
       CastException (new)
          ArrayCastException (was Error in internal/arraycast.d)
       ConvException (was ConvError:Error)
          ConvOverflowException (was ConvOverflowError:ConvError)
       DateParseException (was DateParseError:Error)
       SystemError (see Regan's code posted on thread about std.syserror)
          FileException (was FileException:Exception)
          SocketException (was SocketException:Exception)
             SocketAcceptException
          HostException (was HostException:Exception)
          RegistryException (was RegistryException:Win32Exception)
          ExeModuleException (was ExeModuleException:Exception)
       FormatException (was FormatError:Error)
       ModuleCtorException (was ModuleCtorError:Exception)
       OpenRJException
          DatabaseException
          InvalidKeyException
          InvalidTypeException
       RegExpException (was RegExpError:Error)
       StreamException
          ReadException
          WriteException
          SeekException
          StreamFileException
             OpenException
       StringException
       ThreadException (was ThreadError:Error)
          OutOfThreadsException (new)
       URIException (was URIError:Error)
       UTFException (was UtfError:Error)
       ZipException
       ZlibException

 Notes:
 1. removed std.windows.registry.Win32Exception since it overlaps with
      SystemError for Windows
 2. remove FooError aliases for std.stream exceptions
 3. some exceptions might be thrown with SystemError causes
      (eg StreamFileException, ThreadException)
 4. RegistryException is thrown once without a system error code
 5. NotSupportedException will be a cause in
      - std.mmfile some thrown FileExceptions
      - std.stream in a StreamException that replaces a raw Exception
      - std.zip in several ZipExceptions
 6. Backwards incompatibilities are limited (hopefully) to class names
 involving Error
    and subclassing Error. The subclassing Error switches to Exception

    for asserts and switch defaults don't subclass Exception in the new
 scheme.
 7. The array errors now subclass general reusable errors.

 Exception is defined as
 class Exception {
     char[] msg;
     Object cause; // new

     this(char[] msg, Object cause = null) { // new
         this.msg = msg;
         this.cause = cause; // new
     }

     void print() {
         printf("%.*s\n", msg);
         if (cause) cause.print(); // new
     }

     char[] toString() { return msg; }
 }

 For the definition of SystemError see Regan's post
 digitalmars.D/21282

 Questions:
 1. what should the top few lines of the hierarchy look like?
 2. should modules that currently reuse one exception create subclasses?
 3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
      throw a raw Exception)
 4. what is missing?

Apr 14 2005
next sibling parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
If I may complement my ealier proposal, it should be obvious that subject
experts should have some kind of real-life industry knowledge and experience
in the field... The last thing we want is having new grads drafting
proposals... (not that I have anything against new grads mind you).

The subjects experts could even be voted on by the community itself (with
prehaps Walter having a veto).

Max


"Maxime Larose" <mlarose broadsoft.com> wrote in message
news:d3lpvn$te3$1 digitaldaemon.com...
 Comments:
 1. Assertion Failure and sub-classes should have stack tracing. Should

 then have a common ancestor with Exceptions? (see my post in other

 It would be cleaner if all stack-traced object inherited through the same
 base object, but the functionality can be imported by other means.
 2. As others have said, I would definitely rename SystemError to
 SystemException (deprecating the old name for a while perhaps). It is

 a sore thumb...
 3. I would trim on the numbers of exceptions. Examples:
 #1: ParamException is enough, I don't think ParamNullException and
 ParamRangeException are needed. Less exceptions means more consistency
 overall in D programs. ParamException means the client code screwed up.
 Stack trace should tell you where.
 #2: ArrayCopyException... same thing: parent class is enough.
 #3: Difference between NotSupportedException and NotImplementedException?
 Conceptually, I undersand there is a difference. In practice though, it
 means you called code that does nothing. I wouldeliminate one of the two.
 #4: Base64CharException: parent is enough
 #5: Shouldn't DateParseException be a ParamException?
 #6: ArrayCastException: parent is enough
 #7: What do StringException, ThreadException, ZipException and

 mean in practice? It tells us *where* the exception occured, not *what*
 occured. The exception name should refer to what occured. For instance, if
 Zlib failed because a file was not found, a FileOpenException should be
 sent.

 Honestly, before we reinvent the wheel, I believe we should take a long

 look at own C# and Java define their exception hierarchy and mimic it as
 much as possible. These languages have been in the field for some time and
 some thought went into their exceptions hierarchy design. I would leverage
 this thought process as much as possible.

 The reason I'm saying that is that somehow this hierarchy seems

 It seems to stem from a desire to map what is currently there to something

 little better (which would in itself be a *very* good thing, don't get me
 wrong). However, I believe a more in-depth redesign would be more
 profitable.

 ***
 Walter, Ben, and all,

 Taking a step back, I see in this community people actively participating,
 obviously willing to improve the language and make things better. This is
 extremely valuable. Why not use these resources and this talent in a

 productive manner? Maybe I have been away from newgroup for too long, but
 all these posts back and forth hardly seem productive to me. What seems to
 be going on is endless debates about points of detail, while overall not
 much is achieved. Don't get me wrong, debating is good. As long as it

 somewhere... I have proposed to spend time investigating stack tracing.

 Ben are intend on redesigning the exception hierarchy. I am sure other
 people would like to contribute in various other ways.

 Why doesn't Walter "elect" some people to make high level design proposals
 on chosen topics?  I'm sure that over the years he's come to recognize
 individuals who have made a sizeable contribution to D (like you Ben).
 The idea would be to channel all our ideas to one person responsible for
 drafting a high level design about a specific topic (subject expert).

 would later appose his seal (or not) on that document and implementation
 could begin, by Walter himself or by a designated individual(s). Walter
 would have the last word: if he believes the document does not adequately
 covers possible design alternatives and/or that the suggested amendment is
 inappropriate, he could veto it (at a political price, of course... ;)

 The workload would be shared between Walter and the community and I am

 we would all reap the benefits quite rapidly. That is how open source
 projects work anyway, no? Walter would be the big Kauna and he would have

 few lieutenants working for him. I know I'm not proposing anything new. It
 just appears to me that even at this point, Walter probably can't cope

 all the threads, all the suggestions, all the bugs, etc.

 Anyway, the bottom line for me I guess is that I'm willing to make a
 contribution to D if I can because I believe it has a lot of potential.
 However, I have no time to spend in newsgroup debating endlessly. I

 it is probably the same for the most interesting elements in this

 I'm available, use me or lose me!  ;)

 No kidding, even writing this, I'm afraid I'm losing my time. What if
 Walter's idea is that the exception hierarchy is 100% fine as it is? What
 impact do we have? On the other hand, if Walter elected you Ben as subject
 expert on this matter, well, I'd spend 5 times as much time as I spent
 writing this, making research on my own and proposing amendments a lot

 tangible than "super-class is enough". I'd give alternatives, examples,

 to make my point and try to convince you because in the end you would be
 writing the official proposal. We all know that consensus is something
 unachievable, so there must be one person to receive all comments on a

 subject and weighs alternatives. As it stands, who's responsible for

 a decision? At this stage, the D community lives on hope...

 So, Walter, what say you?

 Max



 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3kkph$2t76$1 digitaldaemon.com...
 Over the past few days/weeks I've been going over the phobos exception
 usage. Below is my proposal for modifying the phobos exception class
 inheritance hierarchy (indenting indicates subclassing). I have no idea


 Walter would actually accept anything close to this proposal, but I


 what the heck. See notes and questions at the end, too.

 Object
    OutOfMemory
    AssertionFailure (was AssertError:Error)
       NoSwitchDefault (was SwitchError:Error)
    Exception
       ParamException (new)
          ParamNullException (new)
          ParamRangeException (new)
       IndexException (new)
          ArrayBoundsException (was ArrayBoundsError:Error)
       CollectionCopyException (new)
          ArrayCopyException (was Error in internal/arraycat.d)
       NotSupportedException (new)
       NotImplementedException (new)
       AddressException
       Base64Exception
          Base64CharException
       CastException (new)
          ArrayCastException (was Error in internal/arraycast.d)
       ConvException (was ConvError:Error)
          ConvOverflowException (was ConvOverflowError:ConvError)
       DateParseException (was DateParseError:Error)
       SystemError (see Regan's code posted on thread about std.syserror)
          FileException (was FileException:Exception)
          SocketException (was SocketException:Exception)
             SocketAcceptException
          HostException (was HostException:Exception)
          RegistryException (was RegistryException:Win32Exception)
          ExeModuleException (was ExeModuleException:Exception)
       FormatException (was FormatError:Error)
       ModuleCtorException (was ModuleCtorError:Exception)
       OpenRJException
          DatabaseException
          InvalidKeyException
          InvalidTypeException
       RegExpException (was RegExpError:Error)
       StreamException
          ReadException
          WriteException
          SeekException
          StreamFileException
             OpenException
       StringException
       ThreadException (was ThreadError:Error)
          OutOfThreadsException (new)
       URIException (was URIError:Error)
       UTFException (was UtfError:Error)
       ZipException
       ZlibException

 Notes:
 1. removed std.windows.registry.Win32Exception since it overlaps with
      SystemError for Windows
 2. remove FooError aliases for std.stream exceptions
 3. some exceptions might be thrown with SystemError causes
      (eg StreamFileException, ThreadException)
 4. RegistryException is thrown once without a system error code
 5. NotSupportedException will be a cause in
      - std.mmfile some thrown FileExceptions
      - std.stream in a StreamException that replaces a raw Exception
      - std.zip in several ZipExceptions
 6. Backwards incompatibilities are limited (hopefully) to class names
 involving Error
    and subclassing Error. The subclassing Error switches to Exception

    for asserts and switch defaults don't subclass Exception in the new
 scheme.
 7. The array errors now subclass general reusable errors.

 Exception is defined as
 class Exception {
     char[] msg;
     Object cause; // new

     this(char[] msg, Object cause = null) { // new
         this.msg = msg;
         this.cause = cause; // new
     }

     void print() {
         printf("%.*s\n", msg);
         if (cause) cause.print(); // new
     }

     char[] toString() { return msg; }
 }

 For the definition of SystemError see Regan's post
 digitalmars.D/21282

 Questions:
 1. what should the top few lines of the hierarchy look like?
 2. should modules that currently reuse one exception create subclasses?
 3. when is it ok to just throw Exception? (ie - should internal/gc/gc.d
      throw a raw Exception)
 4. what is missing?


Apr 14 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Maxime Larose" <mlarose broadsoft.com> wrote in message 
news:d3lu7o$11bg$1 digitaldaemon.com...
 If I may complement my ealier proposal, it should be obvious that subject
 experts should have some kind of real-life industry knowledge and 
 experience
 in the field... The last thing we want is having new grads drafting
 proposals... (not that I have anything against new grads mind you).

 The subjects experts could even be voted on by the community itself (with
 prehaps Walter having a veto).

 Max

I'm not sure what you are referring to. What new grad and what proposal do you object to?
Apr 14 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Maxime Larose" <mlarose broadsoft.com> wrote in message 
news:d3lu7o$11bg$1 digitaldaemon.com...
 If I may complement my ealier proposal, it should be obvious that subject
 experts should have some kind of real-life industry knowledge and 
 experience
 in the field... The last thing we want is having new grads drafting
 proposals... (not that I have anything against new grads mind you).

 The subjects experts could even be voted on by the community itself (with
 prehaps Walter having a veto).

 Max

If you were referring to me here are some google search strings for info about my background (google find me back to 1985). "hinkle hackers guide to adam" (made $20K on those books which was good money in high-school). In 85 or so I switched to the mac. I was the primary coder for later releases of MacMath (google for "Cornell MacMath") in the late 80's early 90's. Did non-commercial coding in grad school. Then in 99 went to "real" commercial software houses - but honestly it's the same thing as the commercial stuff I did in the 80's and 90's. Even if you weren't referring to me it was fun for me to surf around through the past and relive those good ol' days. Enjoy the time-warp. :-)
Apr 14 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 Then in 99 went to "real" commercial software houses

Apr 14 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d3lu7o$11bg$1 digitaldaemon.com>, Maxime Larose says...
If I may complement my ealier proposal, it should be obvious that subject
experts should have some kind of real-life industry knowledge and experience
in the field... The last thing we want is having new grads drafting
proposals... (not that I have anything against new grads mind you).

FWIW, I've heard fantastic suggestions from "new grads" and terrible suggestions from seasoned programmers. I would rather evaluate each suggestion on its own merit than filter based on experience.
The subjects experts could even be voted on by the community itself (with
prehaps Walter having a veto).

I don't know how well an official vote would work in this forum, but every topic gets an implicit vote through responses. It's generally pretty easy to tell who likes an idea and who doesn't even without a show of hands. Sean
Apr 14 2005
parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
 from seasoned programmers.  I would rather evaluate each suggestion on its

 merit than filter based on experience.

I absolutely agree. I couldn't care less about experience myself. What I was trying to say is that the person writing the official draf should have enough experience to weighs the pros and the cons of each design/architecture approach. Like it or not, the more stuff you have seen, the more you know about what is done in the field (and perhaps more importantly what shouldn't be done). A perspective that newbies lack. How do you know a design is better than another? Often, the poor design looks "fishy" without you really knowing what is wrong with it. By thinking more about it, the problems with the fishy design are exposed. Call it whatever you want (intuition, etc.), in my book that's experience. Granted there are "experienced" people that are experienced at making crap. They wouldn't know a bad design from a good one if you explained it to them a 100 times. I'd take a newbie anytime over these people. I'm *not* suggesting we filter any suggestion based on experience. As you say, let every suggestion stand on its own merit. (And no Ben, I wasn't referring to you! ;) Max "Sean Kelly" <sean f4.ca> wrote in message news:d3m9sq$1e5t$1 digitaldaemon.com...
 In article <d3lu7o$11bg$1 digitaldaemon.com>, Maxime Larose says...
If I may complement my ealier proposal, it should be obvious that subject
experts should have some kind of real-life industry knowledge and


in the field... The last thing we want is having new grads drafting
proposals... (not that I have anything against new grads mind you).

FWIW, I've heard fantastic suggestions from "new grads" and terrible

 from seasoned programmers.  I would rather evaluate each suggestion on its

 merit than filter based on experience.

The subjects experts could even be voted on by the community itself (with
prehaps Walter having a veto).

I don't know how well an official vote would work in this forum, but every

 gets an implicit vote through responses.  It's generally pretty easy to

 likes an idea and who doesn't even without a show of hands.


 Sean

Apr 14 2005
parent "Carlos Santander B." <csantander619 gmail.com> writes:
Maxime Larose wrote:
 
 I absolutely agree. I couldn't care less about experience myself. What I was
 trying to say is that the person writing the official draf should have
 enough experience to weighs the pros and the cons of each
 design/architecture approach. Like it or not, the more stuff you have seen,
 the more you know about what is done in the field (and perhaps more
 importantly what shouldn't be done). A perspective that newbies lack. How do
 you know a design is better than another? Often, the poor design looks
 "fishy" without you really knowing what is wrong with it. By thinking more
 about it, the problems with the fishy design are exposed. Call it whatever
 you want (intuition, etc.), in my book that's experience. Granted there are
 "experienced" people that are experienced at making crap. They wouldn't know
 a bad design from a good one if you explained it to them a 100 times. I'd
 take a newbie anytime over these people.

LOL!
 
 I'm *not* suggesting we filter any suggestion based on experience. As you
 say, let every suggestion stand on its own merit.
 
 (And no Ben, I wasn't referring to you! ;)
 
 Max
 
 

-- Carlos Santander Bernal JP2, you'll always live in our minds
Apr 14 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Maxime Larose" <mlarose broadsoft.com> wrote in message 
news:d3lpvn$te3$1 digitaldaemon.com...
 Comments:
 1. Assertion Failure and sub-classes should have stack tracing. Should 
 they
 then have a common ancestor with Exceptions? (see my post in other 
 thread).
 It would be cleaner if all stack-traced object inherited through the same
 base object, but the functionality can be imported by other means.

Adding a common base class between Object and Exception would be easily added with 100% backwards compatibility once stack traces became possible. Why cross that bridge before we need to? In other words, with the hierarchy I've proposed we leave open the option of how to implement stack tracing. Given that it doesn't exist yet it would be premature to impose any API for it. If I'm mistaken about my assertion that adding a base class later is 100% backwards compatible then I totally agree we need to figure this out now.
 2. As others have said, I would definitely rename SystemError to
 SystemException (deprecating the old name for a while perhaps). It is 
 really
 a sore thumb...

ok - I'm very open to hearing from people. I have no strong opinion either way. So please people speak up.
 3. I would trim on the numbers of exceptions. Examples:
 #1: ParamException is enough, I don't think ParamNullException and
 ParamRangeException are needed. Less exceptions means more consistency
 overall in D programs. ParamException means the client code screwed up.
 Stack trace should tell you where.

As I explained in another thread ParamNull is useful for two reasons: 1) shortens the throw code and makes it more consistent. All I have to type is throw new ParamNullException("var name") instead of throw new ParamException("Parameter can't be null","var name") Since null parameter checks are very common it makes sense to make it easy. 2) allows different exceptions for something being null and something being null but out of the desired range or for some other reason. I could see removing ParamRangeException, though, and having user code just throw a ParamException for those.
 #2: ArrayCopyException... same thing: parent class is enough.

sounds reasonable.
 #3: Difference between NotSupportedException and NotImplementedException?
 Conceptually, I undersand there is a difference. In practice though, it
 means you called code that does nothing. I wouldeliminate one of the two.

It's a useful distinction I picked up from Java. You throw NotImpl in stuff you haven't gotten to yet but plan to and NotSupported in stuff that the OS or whatever won't ever support.
 #4: Base64CharException: parent is enough

could be. I just kept what was there before and didn't look into that very closely.
 #5: Shouldn't DateParseException be a ParamException?

good idea
 #6: ArrayCastException: parent is enough

opCast overloads should be able to throw a similar exception as casting an array IMO. Currently casting an array throws a bare Error so we could just go back to that.
 #7: What do StringException, ThreadException, ZipException and 
 ZlibException
 mean in practice? It tells us *where* the exception occured, not *what*
 occured. The exception name should refer to what occured. For instance, if
 Zlib failed because a file was not found, a FileOpenException should be
 sent.

That's what the 'cause' is for. It can be used to both chain exceptions as they get caught and thrown up the stack or it can be used to indicate what happened that caused the first exception to be thrown. In my original post I indicated where I think 'cause' should be used but that was a first pass and people who know more about the particular modules should do whatever they think makes sense. To address your particular example of Zlib and file-not-found I can't see any file management in std.zlib so I'm not sure what you are referring to.
 Honestly, before we reinvent the wheel, I believe we should take a long 
 hard
 look at own C# and Java define their exception hierarchy and mimic it as
 much as possible. These languages have been in the field for some time and
 some thought went into their exceptions hierarchy design. I would leverage
 this thought process as much as possible.

agreed.
 The reason I'm saying that is that somehow this hierarchy seems 
 contrived...
 It seems to stem from a desire to map what is currently there to something 
 a
 little better (which would in itself be a *very* good thing, don't get me
 wrong). However, I believe a more in-depth redesign would be more
 profitable.

please keep the suggestions coming. My proposal was trying to rearrange and unify the existing exceptions so I could very well believe it didn't go far enough in changing things around. Keep in mind the details of the hierarchy will change as phobos modules move around and change. [snip]
 ***
 Walter, Ben, and all,

 Taking a step back, I see in this community people actively participating,
 obviously willing to improve the language and make things better. This is
 extremely valuable. Why not use these resources and this talent in a 
 more...
 productive manner? Maybe I have been away from newgroup for too long, but
 all these posts back and forth hardly seem productive to me. What seems to
 be going on is endless debates about points of detail, while overall not
 much is achieved. Don't get me wrong, debating is good. As long as it 
 leads
 somewhere... I have proposed to spend time investigating stack tracing. 
 You
 Ben are intend on redesigning the exception hierarchy. I am sure other
 people would like to contribute in various other ways.

I'm confident *something* will happen - the question is exactly what Walter (and the community) is willing to accept. Walter goes with the community on many things (though not all obviously) so as long as we have an open and representative debate I see it as all good stuff. [snip good stuff]
Apr 14 2005