Hi Simo, Simone Tripodi wrote:
>>>>> A suggestion: >>>>> >>>>> we are often using the String.format() method to format Exception >>>>> messages - which is very good, IMHO - and since we are introducing a >>>>> new Exception we can take advantage for reducing its use, centralizing >>>>> the message format in the new exception itself, have a look at the >>>>> Digester's ErrorMessage <http://s.apache.org/wiR> >> >> A better approach is IMHO the Contexted(Runtime)Exception of the >> oac.lang3.exception package. Instead of writing a prose for the message >> text, you can use a short informative statement and add all relevant >> additional information in a structured way with the possibility to be >> evaluated properly by a client. You may even enrich the information at >> higher levels by catching the exception, adding the info and rethrow it >> again. >> > > I like the approach, thanks Jörg!!! I think we can reuse some ideas to > improve the BU2 Exceptions design. > > Contexted(Runtime)Exception is good for multi purposes applications > and dynamic contexts, BU2 has already known contexts, i.e. in a > potential PropertyNotFoundException the context is identified by the > missing property in the target class, so BeanReflectionException could > become kind of Contexted(Runtime)Exception and > PropertyNotFoundException could just be > > PropertyNotFoundException( String propertyName, Class<?> target, > Throwable cause ) > { > // impl here > } I think you missed the point. This "context" has nothing to do with the one of BU2. If PropertyNotFoundException where a ContextedRuntimeException, you would have implemented something like: PropertyNotFoundException( String propertyName, Class<?> target, Throwable cause ) { super("Property not found", cause); setContextValue("Property name", propertyName); setContextValue("Bean type", target); } and if this exception is thrown somewhere deep in a subroutine you could add more context with e.g.: try { // call somthing that throws this PropertyNotFoundException } catch (ContextedRuntimeException e) { throw e.addContextValue("File", filename); } The point is with "Property %s not found in %s type" you're embedding the relevant data in the message text and a client would have to parse the text if a special handling is required. And you may have to nest the exceptions deeper as necessary to add additional information. The message is: ========== %< ======== AnotherException: Error processing file %s at ... caused by: PropertyNotFoundException: Property %s not found in %s type at ... ========== %< ======== vs. ========== %< ======== PropertyNotFoundException: Property not found Property Name: %s Bean type: %s File: %s at ... ========== %< ======== The general implementation decision is the consequent usage of exceptions with context or to use them not at all. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
