Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer (LCIE)
Next: best simple Java ETL
From: Roedy Green on 13 Jan 2010 22:05
On Wed, 13 Jan 2010 13:43:51 +0100, Erik <et57(a)hotmail.com> wrote,
quoted or indirectly quoted someone who said :

>the computer jump to "finally" a

You can use a hammer as a can opener, but that is not its intended
use. Similarly for finally.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one�s contributions to computer science.
~ Donald Ervin Knuth (born: 1938-01-10 age: 72)
From: Driss on 17 Jan 2010 13:04
On Jan 13, 6:45 pm, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote:
> Andreas Leitgeb wrote:
....
> > PS: That would be only for analyzing the problem at hand. I guess
> >   many here would strongly frown at a catch (Throwable t) in production
> >   code, and even frown at the catch(Exception e).
>
> 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.

Definitely.

Another very valid reason to use them is to report the problem.

We've got a client-side application that "phones home" (the user know
about the feature) one of our Webapp server when it catches a
Throwable
that shouldn't have happened): it is sending us a Base64 encoded
Proguarded stack trace.

Moreover there's a whole category of "self healing" cases where you
can have a non-essential functionality of a software crashing that
should not take down the whole program.


> I suppose some may argue that the Java program should just always be
> initialized with a large enough heap, but in this case a) unfortunately,
> because of the way Java works, it is not really all that practical to
> deliver simple Java programs to arbitrary users while ensuring the heap
> size is set larger than the default (i.e. as far as I know, there's no
> way to configure that setting within the .jar file itself),

On Windows we went with a hack where a java 'stub' takes care of
invoking the "real" jar with the correct JVM parameters (in our
case the -Xmx parameter depends on how much memory the system has).

On OS X we use a Bash shell script that sets the correct JVM
parameters
before calling the OS X Java stub (which itself calls our 'real' jar).


> ... and b) there
> would still always be the possibility of exceeding what's available, but
> in a completely recoverable way, no matter what the heap size is set to.

I 100% agree with that too :)



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