View mode: basic / threaded / horizontal-split · Log in · Help
October 22, 2008
Re: Change the name of ArrayBoundsException in druntime
Sean Kelly wrote:
> 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

Yes it's longer but I gave three suggestions. I just don't want Array in 
the name so it can be used in general case.
October 22, 2008
Re: Change the name of ArrayBoundsException in druntime
Sean Kelly Wrote:

> 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?

What is the criteria for choosing exception verses error? How would this tie into non-recoverable errors discussed with pure function exception handling?


> 
> 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
October 22, 2008
Re: Change the name of ArrayBoundsException in druntime
Jason House wrote:
> Sean Kelly Wrote:
> 
>> 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?
> 
> What is the criteria for choosing exception verses error? How would this tie into non-recoverable errors discussed with pure function exception handling?

Errors represent situations which are typically non-recoverable--program 
logic errors, for example, or situations where data corruption may have 
occurred--while Exceptions represent the bulk of normal execution 
errors, including OutOfMemory conditions.

Regarding pure functions... are you talking about the nothrow guarantee? 
 I haven't given it much thought, but I'd be inclined to say that it's 
legal for a nothrow function to actually throw a child of Error but not 
Exception.  That ignores OutOfMemoryException though, which is something 
that the programmer shouldn't have to handle.  At the same time, I'd 
consider an out of memory condition to be quite recoverable, so...


Sean
October 22, 2008
Re: Change the name of ArrayBoundsException in druntime
On Wed, Oct 22, 2008 at 7:13 PM, Sean Kelly <sean@invisibleduck.org> wrote:
> Errors represent situations which are typically non-recoverable--program
> logic errors, for example, or situations where data corruption may have
> occurred--while Exceptions represent the bulk of normal execution errors,
> including OutOfMemory conditions.

How, pray tell, is an app supposed to recover from an out-of-memory condition?
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
Jarrett Billingsley wrote:
> On Wed, Oct 22, 2008 at 7:13 PM, Sean Kelly <sean@invisibleduck.org> wrote:
>> Errors represent situations which are typically non-recoverable--program
>> logic errors, for example, or situations where data corruption may have
>> occurred--while Exceptions represent the bulk of normal execution errors,
>> including OutOfMemory conditions.
> 
> How, pray tell, is an app supposed to recover from an out-of-memory condition?

By releasing dynamically allocated memory.  I'd expect some to be 
released automatically as the stack is unrolled to the catch point 
anyway.  For example:

void main()
{
    try { fn(); }
    catch( Exception e ) {}
    int[] x = new int[16384];
}

void fn()
{
    int[] x = new int[16384];
    fn();
}

Eventually this app will run out of memory (hopefully before it runs out 
of stack space) and an OutOfMemoryException will be thrown.  As the 
stack is unwound, all valid references to this memory will be released. 
 So the allocation in main() should trigger a collection which frees up 
all the now-unreferenced memory, thus allowing the allocation in main() 
to succeed.

For manual recovery, consider an app that does a great deal of internal 
caching.  On an OutOfMemory condition the app could clear its caches and 
 then retry the operation.  This is probably a bad example, but I think 
the general idea of trapping and recovering from such a state is 
potentially valid.


Sean
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
On Wed, Oct 22, 2008 at 8:02 PM, Sean Kelly <sean@invisibleduck.org> wrote:
> For manual recovery, consider an app that does a great deal of internal
> caching.  On an OutOfMemory condition the app could clear its caches and
>  then retry the operation.  This is probably a bad example, but I think the
> general idea of trapping and recovering from such a state is potentially
> valid.

I think that's probably a valid thing to try, and considered it after
posting.  However, without language support for restarting code at the
point of the 'throw' it seems like it wouldn't be all that useful.
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
On Thu, Oct 23, 2008 at 9:11 AM, Jarrett Billingsley
<jarrett.billingsley@gmail.com> wrote:
> On Wed, Oct 22, 2008 at 8:02 PM, Sean Kelly <sean@invisibleduck.org> wrote:
>> For manual recovery, consider an app that does a great deal of internal
>> caching.  On an OutOfMemory condition the app could clear its caches and
>>  then retry the operation.  This is probably a bad example, but I think the
>> general idea of trapping and recovering from such a state is potentially
>> valid.
>
> I think that's probably a valid thing to try, and considered it after
> posting.  However, without language support for restarting code at the
> point of the 'throw' it seems like it wouldn't be all that useful.

I think a more common recoverable situation would be an app where user
requests opening up a huge image.
The app tries to allocate space for the huge image and fails with
OutOfMemory.  So the app then gives up on creating that huge image and
reports to the user "Can't do that.  Please buy me some more RAM or
turn on some Virtual Memory."  But there's still plenty of memory for
working on the images that are already loaded.  It shouldn't be fatal.

--bb
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
On Wed, 22 Oct 2008 17:02:22 -0700, Sean Kelly wrote:

> Jarrett Billingsley wrote:
>> On Wed, Oct 22, 2008 at 7:13 PM, Sean Kelly <sean@invisibleduck.org>
>> wrote:
>>> Errors represent situations which are typically
>>> non-recoverable--program logic errors, for example, or situations
>>> where data corruption may have occurred--while Exceptions represent
>>> the bulk of normal execution errors, including OutOfMemory conditions.
>> 
>> How, pray tell, is an app supposed to recover from an out-of-memory
>> condition?
> 
> By releasing dynamically allocated memory.  I'd expect some to be
> released automatically as the stack is unrolled to the catch point
> anyway.  For example:
> 
> void main()
> {
>      try { fn(); }
>      catch( Exception e ) {}
>      int[] x = new int[16384];
> }
> 
> void fn()
> {
>      int[] x = new int[16384];
>      fn();
> }
> 
> Eventually this app will run out of memory (hopefully before it runs out
> of stack space) and an OutOfMemoryException will be thrown.  As the
> stack is unwound, all valid references to this memory will be released.
>   So the allocation in main() should trigger a collection which frees up
> all the now-unreferenced memory, thus allowing the allocation in main()
> to succeed.
> 
> For manual recovery, consider an app that does a great deal of internal
> caching.  On an OutOfMemory condition the app could clear its caches and
>   then retry the operation.  This is probably a bad example, but I think
> the general idea of trapping and recovering from such a state is
> potentially valid.
> 
> 
> Sean

I think a good reason for keeping it an exception (ie recoverable) is 
that out of memory may not be the fault of the program. A completely 
correct program can be given an out of memory error, especially if 
another program (like your example) eats it up, would you want your whole 
system to come to an end?
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
Denis Koroskin wrote:
> 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 ?

That's not my code, although it's obviously based on my code (not 
acknowledged!)
October 23, 2008
Re: Change the name of ArrayBoundsException in druntime
Sean Kelly wrote:
> 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

Ah NOOOOO! Please don't make an out of memory catchable with a plain 
catch(Exception) .... In most programs... pretty much every non-trivial 
desktop application I can think of... an out-of memory state is 
basically unrecoverable. In the few cases it would need to be, there 
would need to be significant handling code, and that would have to be at 
the right location in the program (i.e. when first opening a file), not 
in the closest catch-all block some intern down the hallway may have 
thrown in.

Out of memory is an Error subclass in Java and C#, so there's precedent 
there. catch(Exception) shouldn't be used - but it is, quite often, so 
things that would cause issues that a user could not normally be 
expected to recover from should be Error subclasses.

Indexing I could see being an exception since that's deterministic and 
the user's fault. So I guess I disagree on both counts ;-P. Although 
since index errors don't appear in release modes in D, that gives more 
case for it to be an Error.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home