On Wed, May 28, 2008 at 12:08 PM, Ramkumar R <[EMAIL PROTECTED]> wrote:
> Hi Simon, > After introducing the monitors in various part of the code. Now I am > trying > to remove the exception that are being thrown from these modules. As a > first > step we are removing the exceptions that are safe to remove, by leaving the > critical exceptions like > a) IOException > b) XMLStreamException > c) PriviledegedActionException > d) and ParseConfigurationExceptions > > For the above said exceptions, we need some discussion as how to handle > them. > > I have now raised TUSCANY-2347 to address this issue by leaving the above > exceptions to still throw. > > snip.. Hi Ram, I want to summarize the process here and make sure we are all on the same page. From previous ML discussions we are looking at the case where a user provides a contribution and we want the Tuscany runtime to have the flexibility to report as many validation exceptions as it can up front rather than just reporting the first one. So far the validation code has been changed so that.. A - error and warning messages have been associated with a unique ID and have been moved into resource bundles B - the monitor has been flowed down into the various processing objects C - validation errors or warnings are now logged to the monitor using the unique message ID This leaves the validation code still throwing exceptions all over the place. These exceptions are a mixture of things. 1 - Fundamental exceptions, such as IOException, that mean that any subsequent processing would cause problems 2 - Validation exceptions that mean that subsequent processing would cause problems 3 - Validation exceptions that mean that subsequent processing can continue allowing further validation exceptions to be captured. There are probably several levels of this, e.g. stop processing the current component but other components can be validated. 4 - Validation exceptions that are really warnings IIUC you are disabling type 3 and 4 exceptions to allow a greater range of validation exceptions to be reported before validation processing stops. What happens with type 1 and 2 exceptions. I assume that validation processing stops after one of these exceptions. Have you had any thoughts about how better to categorize and deal with them since your previous post? Regards Simon
