October 22, 2008
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
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
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
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
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
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
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
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
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
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.