Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer (LCIE)
Next: best simple Java ETL
From: Peter Duniho on 13 Jan 2010 13:16
Andreas Leitgeb wrote:
> Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote:
>> IMHO, Throwable can still be worth catching. In fact, just the other
>> day I wrote some code that did, to detect when an attempt to allocate an
>> array that is too large for the current heap failed.
>
> I might be wrong here, but wouldn't it be better to catch the OOM-Error
> explictely for these matters rather than Throwable?

Right, sorry. My point is that a Throwable sub-class isn't necessarily
a bad thing to catch. Just because the base class isn't Exception,
there still may be value in catching a Throwable instance.

Pete
From: Daniel Pitts on 13 Jan 2010 15:24
Peter Duniho wrote:
> Andreas Leitgeb wrote:
>> Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote:
>>> IMHO, Throwable can still be worth catching. In fact, just the other
>>> day I wrote some code that did, to detect when an attempt to allocate
>>> an array that is too large for the current heap failed.
>>
>> I might be wrong here, but wouldn't it be better to catch the
>> OOM-Error explictely for these matters rather than Throwable?
>
> Right, sorry. My point is that a Throwable sub-class isn't necessarily
> a bad thing to catch. Just because the base class isn't Exception,
> there still may be value in catching a Throwable instance.
>
> Pete
Actually, OOM exceptions aren't as useful to catch as they appear at
first glance. You can't really tell if you went a little over the top,
or if some other thread is hogging your memory, or if you went way over
the available memory.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Peter Duniho on 13 Jan 2010 15:39
Daniel Pitts wrote:
> Actually, OOM exceptions aren't as useful to catch as they appear at
> first glance. You can't really tell if you went a little over the top,
> or if some other thread is hogging your memory, or if you went way over
> the available memory.

I agree with the latter. But I don't see why that implies the former.

A serious OOM issue will eventually take down the program, without it
being able to do anything about it. But a simple "this single data
structure is just too big to handle" error is still worth recovering
from, as the program remains in a perfectly usable state.

This allows both the presentation of a specific error message to the
user, as well as giving the user the option to continue with smaller
data (in my particular recent example, it's a program that does some
image manipulation�just because the user can't successfully operate on a
12MP image, that doesn't mean the program shouldn't continue running so
that the user can operate on 5MP images).

That said, re-reading I note that Andreas's original comment was
specifically about a "catch (Throwable t)" clause, where the type being
caught is specifically "Throwable", not some sub-class of that. That
may be less generally useful in production code, because of the other
kinds of errors that may be thrown.

Even so, it seems to me that catching all kinds of errors at the
top-most level of a thread or Swing operation can still be useful. The
problem being that thrown errors don't actually take down the program in
those situations; instead, the run-time just eats the error, allowing
the program to continue in an ill-defined state.

In a perfect world, a program could be written so that it never throws
anything that can't be predicted. But, bugs happen, and even in
bug-free code in some cases the code really just doesn't care _what_
error happens; it's going to treat any error the same. If there's
something going on in the code where upon an exception it's safe to just
back out whatever was going on in that section of the code and report a
failure, then why not?.

It really depends a lot on the code. But especially in code where
side-effects have been avoided, and where a failure does not necessarily
represent a broader program stability issue, I don't see why there would
be a blanket objection to catching non-specific Throwable instances.

I would agree that doing so is probably much overused, and it would be
good to advise people to try to avoid it where it doesn't make sense.
But to say it never makes sense is IMHO far too broad a restriction.

Pete
From: Daniel Pitts on 13 Jan 2010 15:54
Peter Duniho wrote:
> Daniel Pitts wrote:
>> Actually, OOM exceptions aren't as useful to catch as they appear at
>> first glance. You can't really tell if you went a little over the
>> top, or if some other thread is hogging your memory, or if you went
>> way over the available memory.
>
> I agree with the latter. But I don't see why that implies the former.
>
> A serious OOM issue will eventually take down the program, without it
> being able to do anything about it. But a simple "this single data
> structure is just too big to handle" error is still worth recovering
> from, as the program remains in a perfectly usable state.
But, what if you use the last drop of the memory, and some other thread
allocates a small object. That *other* thread will get an OOM for no
apparent reason, and may not be able to recover as gracefully. Catching
OOM from a large allocation might seem useful, but you can still
destabilize your application in unexpected ways.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Peter Duniho on 13 Jan 2010 16:58
Daniel Pitts wrote:
> But, what if you use the last drop of the memory, and some other thread
> allocates a small object. That *other* thread will get an OOM for no
> apparent reason, and may not be able to recover as gracefully.

I'm afraid I don't understand your point. The other thread, not having
a mechanism to recover gracefully, always has that risk, whether or not
some given thread uses "the last drop of the memory". And the scenario
I'm talking about is where the allocation _fails_, which is the exact
opposite of using "the last drop of the memory".

> Catching
> OOM from a large allocation might seem useful, but you can still
> destabilize your application in unexpected ways.

The problem is, an uncaught OOM error doesn't terminate the application.
Failing to catch a problem doesn't affect behavior in other threads in
any predictable way, but neither does catching the same problem.

Pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer (LCIE)
Next: best simple Java ETL