I've persuaded big-W that the exception hierarchy refactoring can wait no longer, but to do so I've had to volunteer to marshal the efforts.

My plan is as follows:

1. Solicit *on-topic* criticisms from the newsgroup

2. Put on my code reviewer's hat, and do a detailed analysis and criticism of the current situation. I'll do this *before* I read any of these criticisms, so as to be unbiased in the review. This means you've a week or so before I'll be digesting and collating any responses from the community, so please take your time to provide considered comments.

3. Amalgamate these two sets of information (along with any prior posts on the subject that I can easily find in the ng) into a (hopefully) simple recommendation for necessary changes to Walter. (If it doesn't fit into three pages (+ listings) or less, I shall consider it a failure.)

4. Release the findings, and Walter's response (if it counters any of the recommendations), to the community for *on-topic* debate.

5. Implement any changes, gratefully taking advantage of any volunteers who popped up their hands in steps 1. or 4..

Note: please resist the temptation to wander OT, or get in slagging matches. I'm barely less busy than Walter at the moment, so am just going to ignore any posts (and their sub-threads) like that, and any useful criticisms contained therein will be wasted.

Hopefully, by the time we hit 0.103 we should be in good shape. If the process works, we might start a trend.

Cheers

Matthew

I'd like to see something like Java's and C#'s support. I'll pick the Java names:

class Throwable {
 this(char[] msg = null, Throwable cause = null) {...}
 Throwable cause() { getter for cause }
 char[] toString() {...}
 void print() {...} // should not allocate any memory
}

class Error : Throwable {...} // non-recoverable error class Exception : Throwable {...} // recoverable error

The only Error subclasses should be AssertError, SwitchError. All subclasses of Exception should have names that end with Exception.


"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:chrebn$12f7$1@digitaldaemon.com...
> I've persuaded big-W that the exception hierarchy refactoring can wait no
longer, but to do so I've had to volunteer to
> marshal the efforts.
>
> My plan is as follows:
>
> 1. Solicit *on-topic* criticisms from the newsgroup
>
> 2. Put on my code reviewer's hat, and do a detailed analysis and criticism
of the current situation. I'll do this
> *before* I read any of these criticisms, so as to be unbiased in the
review. This means you've a week or so before I'll
> be digesting and collating any responses from the community, so please
take your time to provide considered comments.
>
> 3. Amalgamate these two sets of information (along with any prior posts on
the subject that I can easily find in the ng)
> into a (hopefully) simple recommendation for necessary changes to Walter.
(If it doesn't fit into three pages (+
> listings) or less, I shall consider it a failure.)
>
> 4. Release the findings, and Walter's response (if it counters any of the
recommendations), to the community for
> *on-topic* debate.
>
> 5. Implement any changes, gratefully taking advantage of any volunteers
who popped up their hands in steps 1. or 4..
>
> Note: please resist the temptation to wander OT, or get in slagging
matches. I'm barely less busy than Walter at the
> moment, so am just going to ignore any posts (and their sub-threads) like
that, and any useful criticisms contained
> therein will be wasted.
>
> Hopefully, by the time we hit 0.103 we should be in good shape. If the
process works, we might start a trend.
>
> Cheers
>
> Matthew
>
>

Let me add I'd like to see some standard exceptions, too. For example there
should be a module called something like std.exceptions that at least
includes (names from C#):
ArgumentException
OutOfMemoryException
NotSupportedException
NotImplementedException
IndexOutOfBoundsException

I suggest this because I have several libraries that use these exceptions (except OutOfMemory, actually) and writing my own for each library is annoying and error-prone. For example if I want to perform some argument checking on an input to a function and throw an Exception if the argument is illegal then I could write

import std.exceptions;
...
void foo(int must_be_positive) {
  if (must_be_positive <= 0)
    throw new ArgumentException("must_be_positive must be positive");
  ...
}

Plus having a standard "index out of bounds" exception comes in handy with user-defined container classes.

-Ben

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:chsbiq$1hdf$1@digitaldaemon.com...
> I'd like to see something like Java's and C#'s support. I'll pick the Java names:
>
> class Throwable {
>  this(char[] msg = null, Throwable cause = null) {...}
>  Throwable cause() { getter for cause }
>  char[] toString() {...}
>  void print() {...} // should not allocate any memory
> }
>
> class Error : Throwable {...} // non-recoverable error class Exception : Throwable {...} // recoverable error
>
> The only Error subclasses should be AssertError, SwitchError. All
subclasses
> of Exception should have names that end with Exception.
>
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:chrebn$12f7$1@digitaldaemon.com...
> > I've persuaded big-W that the exception hierarchy refactoring can wait
no
> longer, but to do so I've had to volunteer to
> > marshal the efforts.
> >
> > My plan is as follows:
> >
> > 1. Solicit *on-topic* criticisms from the newsgroup
> >
> > 2. Put on my code reviewer's hat, and do a detailed analysis and
criticism
> of the current situation. I'll do this
> > *before* I read any of these criticisms, so as to be unbiased in the
> review. This means you've a week or so before I'll
> > be digesting and collating any responses from the community, so please
> take your time to provide considered comments.
> >
> > 3. Amalgamate these two sets of information (along with any prior posts
on
> the subject that I can easily find in the ng)
> > into a (hopefully) simple recommendation for necessary changes to
Walter.
> (If it doesn't fit into three pages (+
> > listings) or less, I shall consider it a failure.)
> >
> > 4. Release the findings, and Walter's response (if it counters any of
the
> recommendations), to the community for
> > *on-topic* debate.
> >
> > 5. Implement any changes, gratefully taking advantage of any volunteers
> who popped up their hands in steps 1. or 4..
> >
> > Note: please resist the temptation to wander OT, or get in slagging
> matches. I'm barely less busy than Walter at the
> > moment, so am just going to ignore any posts (and their sub-threads)
like
> that, and any useful criticisms contained
> > therein will be wasted.
> >
> > Hopefully, by the time we hit 0.103 we should be in good shape. If the
> process works, we might start a trend.
> >
> > Cheers
> >
> > Matthew
> >
> >
>
>

How about a static opCall in exceptions? This can be done in two ways, I think:

1:
# ArgumentException static opCall(char[] msg)
# {
#     return new ArgumentException(msg);
# }
# ...
# if(something) throw ArgumentException("whatever");

or 2: (my favourite)
# void static opCall(char[] msg)
# {
#     throw new ArgumentException(msg);
# }
# ...
# if(something) ArgumentException("whatever");

Just my two cents...

Nick

Semi-related.  I just posted a bunch of exception issues to the bugs forum. Link is here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1821 I'll write more about exceptions once I've had some time to think about the issue.


Sean

I think we need a good definition of what is an 'Error' and what is an 'Exception'.

I would have said 'OutOfMemory' was an error... however as per Matthew's request lets not debate this here :)

Ben, when you said "The only Error subclasses should be AssertError, SwitchError" did you mean?
  "The only Error subclasses (defined in std.exception) should be AssertError, SwitchError"
or
  "The only Error subclasses (that should ever exist) should be AssertError, SwitchError"
?

On Fri, 10 Sep 2004 10:40:50 -0400, Ben Hinkle <bhinkle@mathworks.com> wrote:
> Let me add I'd like to see some standard exceptions, too. For example there
> should be a module called something like std.exceptions that at least
> includes (names from C#):
> ArgumentException
> OutOfMemoryException
> NotSupportedException
> NotImplementedException
> IndexOutOfBoundsException
>
> I suggest this because I have several libraries that use these exceptions
> (except OutOfMemory, actually) and writing my own for each library is
> annoying and error-prone. For example if I want to perform some argument
> checking on an input to a function and throw an Exception if the argument is
> illegal then I could write
>
> import std.exceptions;
> ...
> void foo(int must_be_positive) {
>   if (must_be_positive <= 0)
>     throw new ArgumentException("must_be_positive must be positive");
>   ...
> }
>
> Plus having a standard "index out of bounds" exception comes in handy with
> user-defined container classes.
>
> -Ben
>
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message
> news:chsbiq$1hdf$1@digitaldaemon.com...
>> I'd like to see something like Java's and C#'s support. I'll pick the Java
>> names:
>>
>> class Throwable {
>>  this(char[] msg = null, Throwable cause = null) {...}
>>  Throwable cause() { getter for cause }
>>  char[] toString() {...}
>>  void print() {...} // should not allocate any memory
>> }
>>
>> class Error : Throwable {...} // non-recoverable error
>> class Exception : Throwable {...} // recoverable error
>>
>> The only Error subclasses should be AssertError, SwitchError. All
> subclasses
>> of Exception should have names that end with Exception.
>>
>>
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message
>> news:chrebn$12f7$1@digitaldaemon.com...
>> > I've persuaded big-W that the exception hierarchy refactoring can wait
> no
>> longer, but to do so I've had to volunteer to
>> > marshal the efforts.
>> >
>> > My plan is as follows:
>> >
>> > 1. Solicit *on-topic* criticisms from the newsgroup
>> >
>> > 2. Put on my code reviewer's hat, and do a detailed analysis and
> criticism
>> of the current situation. I'll do this
>> > *before* I read any of these criticisms, so as to be unbiased in the
>> review. This means you've a week or so before I'll
>> > be digesting and collating any responses from the community, so please
>> take your time to provide considered comments.
>> >
>> > 3. Amalgamate these two sets of information (along with any prior 
>> posts
> on
>> the subject that I can easily find in the ng)
>> > into a (hopefully) simple recommendation for necessary changes to
> Walter.
>> (If it doesn't fit into three pages (+
>> > listings) or less, I shall consider it a failure.)
>> >
>> > 4. Release the findings, and Walter's response (if it counters any of
> the
>> recommendations), to the community for
>> > *on-topic* debate.
>> >
>> > 5. Implement any changes, gratefully taking advantage of any 
>> volunteers
>> who popped up their hands in steps 1. or 4..
>> >
>> > Note: please resist the temptation to wander OT, or get in slagging
>> matches. I'm barely less busy than Walter at the
>> > moment, so am just going to ignore any posts (and their sub-threads)
> like
>> that, and any useful criticisms contained
>> > therein will be wasted.
>> >
>> > Hopefully, by the time we hit 0.103 we should be in good shape. If the
>> process works, we might start a trend.
>> >
>> > Cheers
>> >
>> > Matthew
>> >
>> >
>>
>>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Ben Hinkle" wrote:
> I suggest this because I have several libraries that
> use these exceptions (except OutOfMemory, actually)
> and writing my own for each library is annoying and
> error-prone.

I don't understand why you would have to write your "own for each library".  Why can't you simply write a single exception library that exposes these exceptions and have each of your other libraries use this exception library? Unless I misunderstand, this is exactly the purpose you are proposing that the phobos library's exception implementation would serve.

Regards,
Garett

> I would have said 'OutOfMemory' was an error... however as per Matthew's request lets not debate this here :)

yeah - that could be. I just thought it should be an Exception because user code should be given a chance to free up cached objects that are sitting around in object pools and such. To abort the program because someone tried to allocate a massive object seems extreme.

> Ben, when you said "The only Error subclasses should be AssertError,
> SwitchError" did you mean?
>    "The only Error subclasses (defined in std.exception) should be
> AssertError, SwitchError"
> or
>    "The only Error subclasses (that should ever exist) should be
> AssertError, SwitchError"
> ?

I meant the first one. Users can define Errors - though I can't think of any off the top of my head.

Garett Bass wrote:

> "Ben Hinkle" wrote:
>> I suggest this because I have several libraries that
>> use these exceptions (except OutOfMemory, actually)
>> and writing my own for each library is annoying and
>> error-prone.
> 
> I don't understand why you would have to write your "own for each library".  Why can't you simply write a single exception library that exposes these exceptions and have each of your other libraries use this exception library? Unless I misunderstand, this is exactly the purpose you are proposing that the phobos library's exception implementation would serve.
> 
> Regards,
> Garett

true - I can share my own exceptions between the libraries that I write though it means the exceptions are not in the same package as the library and I have to make sure all my libraries have the same version of the exceptions. I like to keep my libraries independent so that installing one doesn't step on another. Mostly I was thinking of exceptions that make sense across libraries written by possibly different people.

On Sun, 12 Sep 2004 11:57:09 -0400, Ben Hinkle <bhinkle4@juno.com> wrote:
>> I would have said 'OutOfMemory' was an error... however as per Matthew's
>> request lets not debate this here :)
>
> yeah - that could be. I just thought it should be an Exception because user
> code should be given a chance to free up cached objects that are sitting
> around in object pools and such. To abort the program because someone tried
> to allocate a massive object seems extreme.

I agree. So are you also suggesting that an Error is uncatchable?
This needs to be decided upon and well defined.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/