Don't worry Marnie, I'm not planning on making any changes at the moment.
The above discussion has been helpfull though, in getting a more solid idea
of how it will look. Eventually, when there's time...
Rupert
On 12/04/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:
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
> > > >
> > >
> >
>
