> 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 > > 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
