Simon Laws wrote:
On Tue, Apr 15, 2008 at 2:34 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
ant elder wrote:
On Tue, Apr 1, 2008 at 4:43 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]>
wrote:
Simon Nash wrote:
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
OK that's fair. I still think that preventing any 'deployment' is
too
strong, but I can live with it for now and we'll see over time how
that
evolves.
I agree too, thats exactly the type of thing i had in mind. Looks
like we
might all be able to reach some consensus after all :)
...ant
Trying to catch up on discussions from last week. So what is the
consensus? Is there a summary of it anywhere?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'm going to chance my arm here and suggest that the answer to Sebatien's
last question is that consensus was reached and that the consensus is that
1. Errors and wranings are recorded as they are encountered
2. Errors and warnings are reported to the user at the point at which makes
most sense given the current processing context
3. Further processing subsequent to errors and warnings being reported is at
the discretion of the code doing the reporting
This sounds a little vague given the detail of the thread. So mapping to the
monitor code that is being developed....
1. Errors and warnings will be lodged with the monitor as problems as
processing continues. Exceptions won't be thrown. Processing here covers any
processing of user input, i.e. contributions and the artifacts they contain.
2. At some point a phase of processing will be complete, e.g. the
contribution has been read, the composite has been built etc.At this point
problems would be read from the monitor for display to the user. (currently
this will have already happened as our current monitor will just log errors
and warnings as it receives them but you can imagine more capable monitors)
3. The controlling logic may look at the errors and warnings it is reporting
to the user and prevent further processing occurring. Or it may allow
processing to continue. This depends on which bit of processing we are
talking about and what errors have been reported.
Regards
Simon
I agree with the above as a basic framework. The next step is
probably to agree on the default approach that Tuscany should
take for reporting errors and stopping processing when various
kinds of problems have occurred.
For example, by default:
Annotations that violate the SCA spec rules are detected when a
component's implementation is introspected as part of adding
a composite to the domain-level composite. These errors are
reported by messages on System.err. The "add" operation will
fail if any of these errors were detected.
Simon
