Re: Is it bad to catch an Error?

Discussion in 'Java' started by Roedy Green, Dec 20, 2008.

  1. Roedy Green

    Roedy Green Guest

    Normally you are hosed when you get an error, but if you can be clever
    and figure out a way to solve the problem an alternate way, or with
    reduced functionality, I see nothing wrong with catching an error.

    It might be reasonable in a batch process to abandon processing one
    file, and get on with the next. Imagine AMEX deciding to terminate
    because it had trouble processing one transaction.


    There are some errors it makes no sense to catch, e.g. out of memory,
    since you need memory to continue in almost any way.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
    However, he refuses to consider the costs of not implementing Kyoto which the
    famous economist Nicholas Stern estimated at 5 to 20% of GDP
    Roedy Green, Dec 20, 2008
    #1
    1. Advertising

  2. On Dec 20, 1:05 pm, Roedy Green <>
    wrote:
    >...
    > There are some errors it makes no sense to catch, e.g. out of memory,
    > since you need memory to continue in almost any way.


    As mentioned in my first reply, it is relatively
    trivial to recover from an OOME to the point of
    informing the end user of the problem.

    The basic process used was..
    1) Declare a byte[] and assign it.
    2) Prepare a message to the end user, should
    an OOME be encountered.
    3) Try some memory intensive operation, and
    catch the OOME
    4) Once caught, clear the byte[] and show
    the message.

    Some might argue that the byte[] and prepared
    message might constitute the "straw that broke
    the camel's back", and that the app. would have
    finished OK if they had not been declared/prepared.

    Sure, in one run in a thousand that might
    be true, but it is worth doing for the other
    999.

    --
    Andrew Thompson
    http://pscode.org/
    Andrew Thompson, Dec 20, 2008
    #2
    1. Advertising

  3. Roedy Green

    Tom Anderson Guest

    On Fri, 19 Dec 2008, Andrew Thompson wrote:

    > On Dec 20, 1:05 pm, Roedy Green <>
    > wrote:
    >> ...
    >> There are some errors it makes no sense to catch, e.g. out of memory,
    >> since you need memory to continue in almost any way.

    >
    > As mentioned in my first reply, it is relatively trivial to recover from
    > an OOME to the point of informing the end user of the problem.
    >
    > The basic process used was..
    > 1) Declare a byte[] and assign it.
    > 2) Prepare a message to the end user, should
    > an OOME be encountered.
    > 3) Try some memory intensive operation, and
    > catch the OOME
    > 4) Once caught, clear the byte[] and show
    > the message.
    >
    > Some might argue that the byte[] and prepared message might constitute
    > the "straw that broke the camel's back", and that the app. would have
    > finished OK if they had not been declared/prepared.


    Perhaps another tactic might be to throw away some large application data
    structures in order to buy some space to handle the message-showing. If
    you're going to exit after showing the message, then you can chuck almost
    anything. If you're going to carry on, then you have to pick something you
    have some way of regenerating.

    tom

    --
    Beware! Inside pie, there are chickens, gamecubes, Moltres, Raichu,
    and bacteria(in a good way!) -- Wikipedia
    Tom Anderson, Dec 20, 2008
    #3
  4. Tom Anderson wrote:
    > On Fri, 19 Dec 2008, Andrew Thompson wrote:
    >
    >> On Dec 20, 1:05 pm, Roedy Green <>
    >> wrote:
    >>> ...
    >>> There are some errors it makes no sense to catch, e.g. out of
    >>> memory, since you need memory to continue in almost any way.

    >>
    >> As mentioned in my first reply, it is relatively trivial to recover
    >> from an OOME to the point of informing the end user of the problem.
    >>
    >> The basic process used was..
    >> 1) Declare a byte[] and assign it.
    >> 2) Prepare a message to the end user, should
    >> an OOME be encountered.
    >> 3) Try some memory intensive operation, and
    >> catch the OOME
    >> 4) Once caught, clear the byte[] and show
    >> the message.
    >>
    >> Some might argue that the byte[] and prepared message might
    >> constitute the "straw that broke the camel's back", and that the
    >> app. would have finished OK if they had not been declared/prepared.

    >
    > Perhaps another tactic might be to throw away some large application
    > data structures in order to buy some space to handle the
    > message-showing. If you're going to exit after showing the message,
    > then you can chuck almost anything. If you're going to carry on,
    > then
    > you have to pick something you have some way of regenerating.


    That works only f you can guarantee that you've eliminated all of the
    references to the structures. That can be difficult to guarantee and
    tricky to test. I like Andrew's solution because by design there's
    only one pointer to his big byte array.
    Mike Schilling, Dec 20, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Black
    Replies:
    8
    Views:
    4,137
    Xenos
    Aug 20, 2004
  2. Adam
    Replies:
    9
    Views:
    551
    red floyd
    Feb 2, 2006
  3. Joshua Cranmer

    Re: Is it bad to catch an Error?

    Joshua Cranmer, Dec 18, 2008, in forum: Java
    Replies:
    2
    Views:
    349
  4. Daniel Pitts

    Re: Is it bad to catch an Error?

    Daniel Pitts, Dec 18, 2008, in forum: Java
    Replies:
    0
    Views:
    392
    Daniel Pitts
    Dec 18, 2008
  5. rantingrick
    Replies:
    44
    Views:
    1,161
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page