So I'm going to try and re-state the evolving error reporting rules based on the discussion on this thread...
A - If the monitor is passed in then use it and don't throw exceptions explicitly. Parts of our code and 3rd party libaries will throw exceptions so we need to make sure we catch them B - Always report (API TBD) context including appropriate information for the error or warning, for example, Contribution/Composite/Component/Reference|Service/Binding etc. If suitable context information is not directly available B-1 - Extend the calling interface and pass it down (What form does context take? String?) B-2 - Throw an exception and catch it at a point where the context is available (people disliked the idea of accumulating context information in the Monitor) C - Raising a warning should not prevent further processing D - If it's not possible for the Tuscany runtime to continue after an error then make sure that processing stops (How? we need an exception that is only caught at the top). It may not be possible to continue because D-1 The runtime is damaged by the error and will likely throw NPE D-2 Any subsequent errors will be unclear or missleading E - Avoid adding utility methods everywhere the monitor is used. If the monitor interface is no usable as is let's fix it. F - Read/resolve/build/activate/start/stop time warnings and errors should all be handled in the same way. I.e. pass a message to the monitor and decide whether processing can continue G - Run time warning and errors come in several forms G-1 Application errors are thrown by the application and pass over SCA bindings without interference G-2 System errors are thrown as exceptions defined in the SCA API, for example, ServiceRuntimeException G-3 Do we need to record run time system exceptions to the monitor also? Is this covering all the points? Is it right? Regards Simon
