Simon Laws wrote:
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.
In that case what is the difference between a warning and an error. Is it
fatal - the error is so bad I can't even carry on building the model
error - the runtime can build the model but it can't run it
warning - the application can still be run
Yes, exactly. Warnings don't prevent execution but errors do.
Errors don't prevent further detection of errors but fatal errors do.
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
I'm still not convinced about the difference between fatal and error.
Mainly because I think it's likely to be drive by the runtime
implementation rather than and particular application configuration.
Simon
This may be true, but I think it's still useful for the user to know
whether the error stopped all further detection of errors (so there
could be other errors that weren't reported) or whether the error
was caught and allowed further error detection to continue.
Simon
