October 22, 2008
I think the name ArrayBoundsException should be changed to a more general name like BoundsException, OutOfBoundsException or IndexOutOfBoundsException. Then you can use the exception in every class that have some sort of index operation and not just for an array/array class.
October 22, 2008
On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
> I think the name ArrayBoundsException should be changed to a more general name like BoundsException, OutOfBoundsException or IndexOutOfBoundsException. Then you can use the exception in every class that have some sort of index operation and not just for an array/array class.
>

2nded.
October 22, 2008
On Wed, 22 Oct 2008 16:22:02 +0400, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:

> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>> I think the name ArrayBoundsException should be changed to a more general
>> name like BoundsException, OutOfBoundsException or
>> IndexOutOfBoundsException. Then you can use the exception in every class
>> that have some sort of index operation and not just for an array/array
>> class.
>>
>
> 2nded.

Agreed. BTW, why it is not an Error but Exception?
October 22, 2008
Jarrett Billingsley wrote:
> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>> I think the name ArrayBoundsException should be changed to a more general
>> name like BoundsException, OutOfBoundsException or
>> IndexOutOfBoundsException. Then you can use the exception in every class
>> that have some sort of index operation and not just for an array/array
>> class.
>>
> 
> 2nded.

I agree. In fact I wanted to ask you all the following question. What do
you think about the current exception hierarchy in phobos? I think it is
terrible. Each module in std you open, the first piece of code to be
seen is the "class ThisModuleNameException" definition. In many (most?)
cases the module-specific exception does absolutely nothing in addition
to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.

Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!

I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.


Andrei
October 22, 2008
On Wed, 22 Oct 2008 19:06:24 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Jarrett Billingsley wrote:
>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>> I think the name ArrayBoundsException should be changed to a more general
>>> name like BoundsException, OutOfBoundsException or
>>> IndexOutOfBoundsException. Then you can use the exception in every class
>>> that have some sort of index operation and not just for an array/array
>>> class.
>>>
>>  2nded.
>
> I agree. In fact I wanted to ask you all the following question. What do
> you think about the current exception hierarchy in phobos? I think it is
> terrible. Each module in std you open, the first piece of code to be
> seen is the "class ThisModuleNameException" definition. In many (most?)
> cases the module-specific exception does absolutely nothing in addition
> to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.
>
> Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!
>
> I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.
>
>
> Andrei

There is sometimes a need to differentiate between a specific exception and a generic one, even though the former or does nothing.

typedef Exception MyException; // might be a good compromise

try {
    throw new MyException("reason");
} catch (MyException e) {
    // catch concrete exception
} catch (Exception e) {
    // catch generic exception
}

This code currently doesn't work, because compiler thinks that MyException and Exception are of the same type, which is wrong - MyException is kind of a subclass of Exception, as the following sample shows:

typedef Exception MyException;

void main()
{
    MyException me = new MyException("reason");
    Exception e = me; // implicit downcast
    me = e; // doesn't work, it is an upcast
    Object o = me; // ICE! :)
}

Could anyone put it into bugzilla? (I have no access to HTTP currently :()
October 22, 2008
On Wed, 22 Oct 2008 10:06:24 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>Jarrett Billingsley wrote:
>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>> I think the name ArrayBoundsException should be changed to a more general name like BoundsException, OutOfBoundsException or IndexOutOfBoundsException. Then you can use the exception in every class that have some sort of index operation and not just for an array/array class.
>>>
>> 
>> 2nded.
>
>I agree. In fact I wanted to ask you all the following question. What do you think about the current exception hierarchy in phobos? I think it is terrible. Each module in std you open, the first piece of code to be seen is the "class ThisModuleNameException" definition. In many (most?) cases the module-specific exception does absolutely nothing in addition to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.
>
>Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!
>
>I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.
>
>
>Andrei

Good idea. What about exceptions thrown from templated code? I suppose mixins and ordinary template instances  should be treated differently:

modue a;

template Foo()
{
    void Foo()
   {
      throw new Exception;
   }
}

----
module b;

alias Foo!() foo; // Exception's module should probably be 'a' mixin Foo; // Exception's module is 'b'?
October 22, 2008
Denis Koroskin wrote:
> On Wed, 22 Oct 2008 19:06:24 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Jarrett Billingsley wrote:
>>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>>> I think the name ArrayBoundsException should be changed to a more general
>>>> name like BoundsException, OutOfBoundsException or
>>>> IndexOutOfBoundsException. Then you can use the exception in every class
>>>> that have some sort of index operation and not just for an array/array
>>>> class.
>>>>
>>>  2nded.
>>
>> I agree. In fact I wanted to ask you all the following question. What do
>> you think about the current exception hierarchy in phobos? I think it is
>> terrible. Each module in std you open, the first piece of code to be
>> seen is the "class ThisModuleNameException" definition. In many (most?)
>> cases the module-specific exception does absolutely nothing in addition
>> to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.
>>
>> Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!
>>
>> I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.
>>
>>
>> Andrei
> 
> There is sometimes a need to differentiate between a specific exception and a generic one, even though the former or does nothing.
> 
> typedef Exception MyException; // might be a good compromise
> 
> try {
>     throw new MyException("reason");
> } catch (MyException e) {
>     // catch concrete exception
> } catch (Exception e) {
>     // catch generic exception
> }
> 
> This code currently doesn't work, because compiler thinks that MyException and Exception are of the same type, which is wrong - MyException is kind of a subclass of Exception, as the following sample shows:
> 
> typedef Exception MyException;
> 
> void main()
> {
>     MyException me = new MyException("reason");
>     Exception e = me; // implicit downcast
>     me = e; // doesn't work, it is an upcast
>     Object o = me; // ICE! :)
> }
> 
> Could anyone put it into bugzilla? (I have no access to HTTP currently :()

I'd discussed that with Walter. He said that making typedefs
full-fledged classes would be technically difficult.

Andrei
October 22, 2008
Max Samukha wrote:
> On Wed, 22 Oct 2008 10:06:24 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Jarrett Billingsley wrote:
>>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>>> I think the name ArrayBoundsException should be changed to a more general
>>>> name like BoundsException, OutOfBoundsException or
>>>> IndexOutOfBoundsException. Then you can use the exception in every class
>>>> that have some sort of index operation and not just for an array/array
>>>> class.
>>>>
>>> 2nded.
>> I agree. In fact I wanted to ask you all the following question. What do
>> you think about the current exception hierarchy in phobos? I think it is
>> terrible. Each module in std you open, the first piece of code to be
>> seen is the "class ThisModuleNameException" definition. In many (most?)
>> cases the module-specific exception does absolutely nothing in addition
>> to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.
>>
>> Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!
>>
>> I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.
>>
>>
>> Andrei
> 
> Good idea. What about exceptions thrown from templated code? I suppose
> mixins and ordinary template instances  should be treated differently:
> 
> modue a;
> 
> template Foo()
> {
>     void Foo()
>    {
>       throw new Exception;
>    }
> }
> 
> ----
> module b;
> 
> alias Foo!() foo; // Exception's module should probably be 'a'
> mixin Foo; // Exception's module is 'b'?

That's a good point. By the way, where is Don's code to get the name of
the current module?

Andrei

October 22, 2008
On Wed, 22 Oct 2008 20:25:15 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Max Samukha wrote:
>> On Wed, 22 Oct 2008 10:06:24 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Jarrett Billingsley wrote:
>>>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>>>> I think the name ArrayBoundsException should be changed to a more general
>>>>> name like BoundsException, OutOfBoundsException or
>>>>> IndexOutOfBoundsException. Then you can use the exception in every class
>>>>> that have some sort of index operation and not just for an array/array
>>>>> class.
>>>>>
>>>> 2nded.
>>> I agree. In fact I wanted to ask you all the following question. What do
>>> you think about the current exception hierarchy in phobos? I think it is
>>> terrible. Each module in std you open, the first piece of code to be
>>> seen is the "class ThisModuleNameException" definition. In many (most?)
>>> cases the module-specific exception does absolutely nothing in addition
>>> to its base class. The putative reader (including me) tends to scroll non-critically over that passage without even blinking, mumbling in a trance - of course, yes, each module should define at least one exception type.
>>>
>>> Until one day when you stop scrolling and say, wait a minute. This all is repetition. And there are alternatives to catching by type - you can catch the base type and consult a field. And in fact I don't remember seeing code that depends on exceptions thrown from different modules having different types. There's something wrong here!
>>>
>>> I think most exception classes in phobos should be yanked if it's possible for their functionality (often nil) to be moved in the Exception base class. The module name should be a member. If someone needs to deal with an exception thrown from a specific module, they can always inspect the field. We don't need a huge hierarchy for that.
>>>
>>>
>>> Andrei
>>  Good idea. What about exceptions thrown from templated code? I suppose
>> mixins and ordinary template instances  should be treated differently:
>>  modue a;
>>  template Foo()
>> {
>>     void Foo()
>>    {
>>       throw new Exception;
>>    }
>> }
>>  ----
>> module b;
>>  alias Foo!() foo; // Exception's module should probably be 'a'
>> mixin Foo; // Exception's module is 'b'?
>
> That's a good point. By the way, where is Don's code to get the name of
> the current module?
>
> Andrei
>

http://www.dsource.org/projects/meta/browser/trunk/meta/NameOf.d ?
October 22, 2008
Denis Koroskin wrote:
> On Wed, 22 Oct 2008 16:22:02 +0400, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
> 
>> On Wed, Oct 22, 2008 at 6:49 AM, Jacob Carlborg <doobnet@gmail.com> wrote:
>>> I think the name ArrayBoundsException should be changed to a more general
>>> name like BoundsException, OutOfBoundsException or
>>> IndexOutOfBoundsException. Then you can use the exception in every class
>>> that have some sort of index operation and not just for an array/array
>>> class.
>>>
>>
>> 2nded.
> 
> Agreed. BTW, why it is not an Error but Exception?

The Error class was created shortly before release and I didn't get around to reclassifying the exceptions in druntime.  From memory though, I think that OutOfMemoryException and UtfException should remain as-is, but the remaining exceptions should probably be errors.  Any objections?

And as for ArrayBoundsException... how about IndexOutOfBoundsError. It's long, but probably the most self-explanatory.  Also, any value in retaining ArrayBoundsError and having it subclass this?  I'd think not, but figured I'd ask anyway.


Sean
« First   ‹ Prev
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home