Jump to page: 1 28  
Page
Thread overview
Change the name of ArrayBoundsException in druntime
Oct 22, 2008
Jacob Carlborg
Oct 22, 2008
Denis Koroskin
Oct 22, 2008
Sean Kelly
Oct 22, 2008
Jacob Carlborg
Oct 22, 2008
Jason House
Oct 22, 2008
Sean Kelly
Oct 23, 2008
Sean Kelly
Oct 23, 2008
Bill Baxter
Oct 23, 2008
Jesse Phillips
Oct 23, 2008
Robert Fraser
Oct 23, 2008
Sean Kelly
Oct 24, 2008
Robert Fraser
Oct 24, 2008
Bill Baxter
Oct 24, 2008
Robert Fraser
Oct 25, 2008
Jesse Phillips
Oct 25, 2008
Robert Fraser
Oct 26, 2008
Jesse Phillips
Oct 31, 2008
Sean Kelly
Oct 23, 2008
Denis Koroskin
Oct 23, 2008
Denis Koroskin
Oct 23, 2008
Sean Kelly
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
Sean Kelly
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
Robert Fraser
Oct 23, 2008
KennyTM~
Oct 25, 2008
Lars Kyllingstad
Oct 23, 2008
Sergey Gromov
Oct 31, 2008
Sean Kelly
Nov 01, 2008
Denis Koroskin
Oct 22, 2008
Denis Koroskin
Oct 22, 2008
Max Samukha
Oct 22, 2008
Denis Koroskin
Oct 23, 2008
Don
Oct 23, 2008
Robert Fraser
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
David Gileadi
Oct 23, 2008
Sean Kelly
Oct 23, 2008
Bill Baxter
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
Bill Baxter
Oct 23, 2008
Sergey Gromov
Oct 23, 2008
Bill Baxter
Oct 23, 2008
Bill Baxter
Oct 24, 2008
Sergey Gromov
Oct 24, 2008
Robert Fraser
Oct 23, 2008
Sean Kelly
Oct 24, 2008
Robert Fraser
Oct 24, 2008
Robert Fraser
Oct 27, 2008
Bent Rasmussen
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