October 25, 2008
Jesse Phillips wrote:
> On Fri, 24 Oct 2008 16:04:53 -0700, Robert Fraser wrote:
> 
>> Bill Baxter wrote:
>>> On Fri, Oct 24, 2008 at 10:42 AM, Robert Fraser
>>> <fraserofthenight@gmail.com> wrote:
>>>> Sean Kelly wrote:
>>>>> Perhaps I'm simply getting old... when did memory use become
>>>>> irrelevant?
>>>>>  I grant that making an application exception safe is more difficult
>>>>>  if out
>>>>> of memory conditions are considered recoverable, but I don't think
>>>>> it's tremendously more difficult.
>>>> I'm currently studying Computer Engineering at university. I don't
>>>> think a single programming course I've taken has _mentioned_ running
>>>> out of memory (next quarter I'm taking Operating Systems, so hopefully
>>>> that will). One class mentioned memory complexity as a side issue, but
>>>> never got into it. Even at work, I've never been asked to think about
>>>> it.
>>> People do still develop for embedded devices with small memory and/or
>>> no virtual memory.
>>> I'm pretty sure it's still a serious concern if you live in that world.
>>>
>>> --bb
>> I'm not saying it doesn't come up in practice; I'm saying developers are
>> trained not to think about it in most cases. And programming to handle a
>> small amount of memory is a different problem than programming to
>> gracefully fail when the program runs out of memory (for example, my
>> program might only use 10k of RAM... but if that 10k isn't there, it
>> might just crash with an error message).
>>
>> The problem with an OutOfMemoryError being treated as an Exception is
>> that if there are many catch(Exception) blocks, an out-of-memory error
>> will propagate logic bugs across the program (since no one is cleaning
>> up the memory, most allocations will fail). So instead of a nice, clean
>> error, the suer will experience weird and frustrating behavior that
>> doesn't mention memory at all.
> 
> The problem with it being an error is that the programmer has no way to catch and remain usable, 

Sure there is:
catch(OutOfMemoryError)

Just like in Java or .Net. The only difference is that it's not caught by a general catch(Exception)

> leaving the user blissfully unaware he needs to buy more ram. If there are many catch(Exception)'s around, the programmer needs to rethink what he is doing when creating a stable program.

Probably. But when you have a team of 300 programmers, this is a bit harder to do, and catch(Exception) _is_ a powerful tool for generalized recoverable error handling.

> D doesn't force a try or throw of exceptions for this very reason; people usually use the catch(Exception) because they don't know what needs to be caught and don't care but are forced to catch it, not because their program is crashing from an exception (well, that is what I do).

People also use it to say to the user "this didn't work; try something else"? In 99% of cases, this is fine, but when memory is involved, the programmer has a whole lot more to think about and would often want to catch the memory exception at a higher level.
October 26, 2008
On Sat, 25 Oct 2008 15:45:51 -0700, Robert Fraser wrote:

> Jesse Phillips wrote:
>> On Fri, 24 Oct 2008 16:04:53 -0700, Robert Fraser wrote:
>> 
>>> Bill Baxter wrote:
>>>> On Fri, Oct 24, 2008 at 10:42 AM, Robert Fraser <fraserofthenight@gmail.com> wrote:
>>>>> Sean Kelly wrote:
>>>>>> Perhaps I'm simply getting old... when did memory use become
>>>>>> irrelevant?
>>>>>>  I grant that making an application exception safe is more
>>>>>>  difficult if out
>>>>>> of memory conditions are considered recoverable, but I don't think
>>>>>> it's tremendously more difficult.
>>>>> I'm currently studying Computer Engineering at university. I don't think a single programming course I've taken has _mentioned_ running out of memory (next quarter I'm taking Operating Systems, so hopefully that will). One class mentioned memory complexity as a side issue, but never got into it. Even at work, I've never been asked to think about it.
>>>> People do still develop for embedded devices with small memory and/or
>>>> no virtual memory.
>>>> I'm pretty sure it's still a serious concern if you live in that
>>>> world.
>>>>
>>>> --bb
>>> I'm not saying it doesn't come up in practice; I'm saying developers are trained not to think about it in most cases. And programming to handle a small amount of memory is a different problem than programming to gracefully fail when the program runs out of memory (for example, my program might only use 10k of RAM... but if that 10k isn't there, it might just crash with an error message).
>>>
>>> The problem with an OutOfMemoryError being treated as an Exception is that if there are many catch(Exception) blocks, an out-of-memory error will propagate logic bugs across the program (since no one is cleaning up the memory, most allocations will fail). So instead of a nice, clean error, the suer will experience weird and frustrating behavior that doesn't mention memory at all.
>> 
>> The problem with it being an error is that the programmer has no way to catch and remain usable,
> 
> Sure there is:
> catch(OutOfMemoryError)
> 
> Just like in Java or .Net. The only difference is that it's not caught
> by a general catch(Exception)
> 
>> leaving the user blissfully unaware he needs to buy more ram. If there are many catch(Exception)'s around, the programmer needs to rethink what he is doing when creating a stable program.
> 
> Probably. But when you have a team of 300 programmers, this is a bit harder to do, and catch(Exception) _is_ a powerful tool for generalized recoverable error handling.
> 
>> D doesn't force a try or throw of exceptions for this very reason; people usually use the catch(Exception) because they don't know what needs to be caught and don't care but are forced to catch it, not because their program is crashing from an exception (well, that is what I do).
> 
> People also use it to say to the user "this didn't work; try something else"? In 99% of cases, this is fine, but when memory is involved, the programmer has a whole lot more to think about and would often want to catch the memory exception at a higher level.

Oops, from past discussions about the difference I somehow got the idea that an Error couldn't be caught.

While out of memory still falls under recoverable, I can see why putting greater importance over other exceptions would be good.
October 27, 2008
Agreed.

Either that, or superclasss it.

- Bent

"Jacob Carlborg" <doobnet@gmail.com> skrev i meddelelsen news:gdn0ft$u2m$1@digitalmars.com...
> 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 31, 2008
Jesse Phillips wrote:
> On Sat, 25 Oct 2008 15:45:51 -0700, Robert Fraser wrote:
> 
>> Jesse Phillips wrote:
>>>
>>> D doesn't force a try or throw of exceptions for this very reason;
>>> people usually use the catch(Exception) because they don't know what
>>> needs to be caught and don't care but are forced to catch it, not
>>> because their program is crashing from an exception (well, that is what
>>> I do).
>> People also use it to say to the user "this didn't work; try something
>> else"? In 99% of cases, this is fine, but when memory is involved, the
>> programmer has a whole lot more to think about and would often want to
>> catch the memory exception at a higher level.
> 
> Oops, from past discussions about the difference I somehow got the idea that an Error couldn't be caught.
> 
> While out of memory still falls under recoverable, I can see why putting greater importance over other exceptions would be good.

After some thought, I'm inclined to agree.  While an OOM condition might be recoverable without any explicit effort, I think it's a good idea to encourage that it receive special handling by classifying it as an Error.  Since D is a systems language I don't consider any error condition to be necessarily unrecoverable anyway, so reclassifying OutOfMemory doesn't imply anything to me other than that it should be handled explicitly rather than accidentally by trapping and tossing out out as an Exception.


Sean
October 31, 2008
Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Wed, 22 Oct 2008 12:01:36 -0700,
>> Sean Kelly wrote:
>>> 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.
>>
>> Maybe IndexingError ?  There are not necessarily any bounds when you're indexing into an arbitrary collection.
> 
> STL has range_error. I like that because it's rather general.

The terminology matches D's new range concept anyway, which is a nice perk.  Works for me.


Sean
November 01, 2008
On Sat, 01 Nov 2008 01:56:49 +0300, Sean Kelly <sean@invisibleduck.org> wrote:

> Andrei Alexandrescu wrote:
>> Sergey Gromov wrote:
>>> Wed, 22 Oct 2008 12:01:36 -0700,
>>> Sean Kelly wrote:
>>>> 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.
>>>
>>> Maybe IndexingError ?  There are not necessarily any bounds when you're indexing into an arbitrary collection.
>>  STL has range_error. I like that because it's rather general.
>
> The terminology matches D's new range concept anyway, which is a nice perk.  Works for me.
>
>
> Sean

I find range_error way too generic. What is range error? Invalid range?
OutOfRangeError is more suitable imo.

Range!(int) r = ...; // random-access range
int t = r[2]; // okay, within range
int s = r[100]; // error, our of range
1 2 3 4 5 6 7 8
Next ›   Last »