Simon Laws wrote:
Had manager on my mind for some reason. Manager = monitor in this context.
Re. stopping after first error. I was referring to the case where the
runtime is then broken and hence the subsequent errors make no sense.
For example, the code can often report a NPE subsequent to a previous
error report. At least we need to go through each case where an ERROR
is reported and check what subsequent processing might do. However it
seems more consistent just to stop.
Simon
If the runtime is broken then I agree we need to stop. However in
many cases it is possible to detect the error, log it, and continue
without the runtime being broken. I think we should go through the
error cases (message by message) to see which applies in each case.
To make the distinction clearer and more formal, I think it would be
useful to divide the error cases into "fatal" and "non-fatal" based
on whether or not the runtime is able to continue. We could do this
by adding a new category "FATAL" to the current list of problem
severities. This will make it very clear which errors prevent
further processing and error accumulation. It would also provide
consistency because all fatal errors would stop processing and all
warnings and non-fatal errors would continue processing.
For fatal errors, we need a suitable unchecked exception that can
be thrown to abort processing when the error has been logged. For
various reasons I think it will be easier to make the code that
detects the problem throw this exception, rather than having it done
automatically by the monitor. I been doing some work recently on
improved error handling in the domain manager, and I have used this
pattern in my changes. I'll be raising an JIRA for these changes soon,
and I'll post another message describing the pattern I have been
using so that we can discuss it.
Simon
