Jean-Sebastien Delfino wrote:
scabooz wrote:
Hi Folks,
+1 for warnings when the application is developed. +1 for Errors when
you put the application into production. The trick is to know the
difference
between deployment for UT vs. deployment for real.
:-)
Dave
And the other trick is to allow processing of artifacts with errors to
proceed as well in dev, debug and admin scenarios as well.
For example we should be able to load a composite with errors in it, in
the admin tool, to show these errors to the administrator and allow him
to fix them.
Basically it's the same idea as a with Java editor. A Java editor that
wouldn't allow you to edit Java classes with errors wouldn't be very
useful :)
That means: Not throwing an exception that stops everything on the first
error, but instead report errors through the monitors that we already
have in various places in the code.
I agree with this statement that everything should not stop on the first
error. To reuse my compiler analogy, I wouldn't like the compiler to
report only one error every time I run it.
However, this doesn't mean that the faulty class should only produce a
warning that allows execution to proceed. It should still produce an
error that causes deployment of this application to fail, but the error
should be handled in a way that allows it to be batched with other
similar errors to give the user a consolidated failure report.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
