I agree with the vast majority of the discussion (consensus anyway).
We have loads of stuff in JIRAs etc which imho come before rewriting all our
exception handling :-) In light of this, wanted to re-iterate that making
wholesale changes would be lovely - but in the absence of that, please take
care when making assumptions about how thrown exceptions will be handled
higher up.
I don't much care where we log exceptions - so long as we do. Many (most/all
??) user applications using Qpid will use log monitoring to health check
their deployments.
Logging on construction has been used in past projects as a fool proof way
to make sure that exceptions are always logged appropriately. I'd far rather
take the chance that we log (handle) twice in a slightly impure way than (as
we perhaps too often do), catch and do nothing or keep throwing upwards with
the assumption that some calling method cares enough to log it !
Be different if we were having this discussion at project inception. Since
we're not, let's be realistic about how much time this really justifies !
Bfn,
Marnie
On 4/11/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
Yes - In general I'm of the opinion that if you get any exception bubbling
up to the top level handler then you should probably quite... but that may
be a bit severe for the moment.
By top level, obviously what we mean is some sort of uncaught exception
handler for the thread group which all threads are running in.
-- Rob
On 11/04/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
>
> As a top-level handler? To avoid littering it throughout the code? Then
we
> can follow the general principal, that when something bad happens that
you
> cannot deal with, raise it and let it fall through all the way to this
> handler.
>
> On 11/04/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
> >
> > Generally I think
> >
> > catch(Error e)
> > {
> > try
> > {
> > // try to do some log here perhaps
> > }
> > finally
> > {
> > System.exit(1);
> > }
> > }
> >
> > Error is bad :-)
> >
> > On 11/04/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> > >
> > > For OOM I would agree that recover mode == System.exit :)
> > >
> > > On 11/04/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> > > > I'm in definite agreement with this point of view.
> > > >
> > > > As I go through the errors I'm taking note of suspiciously
unhandled
> > > > conditions, and should get around to turning them into JIRA's at
> some
> > > point.
> > > >
> > > > Rupert
> > > >
> > > > On 11/04/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > And there is the current problem. we don't have top-level
error
> > > > > > handlers in place in the broker. Hence things like OutOfMemory
> > > Errors
> > > > > > cause the broker to grind to a halt rather than entering any
> > > recovery
> > > > > > mode.
> > > > >
> > > > >
> > > > > I shall repeat my view that an OOM error should bring
the broker
> to
> > > and
> > > > > *abrupt* halt (rather than a grinding one) since there is
> *nothing*
> > > you
> > > > > can
> > > > > reliably do once you get to this point. The trick is to try to
> > ensure
> > > > > that
> > > > > you never hit this point.
> > > > >
> > > > > However the best thing to do with unrecoverable errors is to
exit
> > > quickly
> > > > > and as cleanly as possible.
> > > > >
> > > > > -- Rob
> > > > >
> > > >
> > >
> > >
> > > --
> > > Martin Ritchie
> > >
> >
>
