Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

I agree totally.  I'm just trying to tread lightly and reduce the 
possibilities for regression errors.  I don't know if there is any reason 
why we would want to continue after an exception, but apparently somebody 
thought there was at some point.

If anybody wants to look at the code in question, it's:

org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), line 
1185.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/webmacro/engine/PropertyOperatorCache.java?rev=1.17&content-type=text/vnd.viewcvs-markup

Keats



On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...> wrote:

> I've tracked this down and patched it locally, but I need to do a bit of 

> regression testing before I commit it.

Great work!

> The problem is a bit esoteric.  It has to do with the fact that there 
can 
> be multiple "set" methods for a primitive type.  The PropertyOperator 
> just tries them all until one works, ignoring any exceptions along the 
> way.  So if you hit an exception in a primitive "set" operation, WM acts 

> as if there was no appropriate method found -- hence the misleading 
error 
> message.
>
> My patch just saves the exception and rethrows it if none of the "set" 
> invocations were successful.

Shouldn't "fail fast" be the real solution here? i.e. if any exception 
occurs, kill it and don't look for more setters... more below...

> One potential issue is that if you have both a "unary" setter and a 
"map" 
> setter, e.g.,
>
> public void setFoo(boolean val){ throw new RuntimeException(); }
> public void set(String key, Object val){ map.put(key, val);
> }
> ...
> #set $var.Foo=true
>
> Under the current implementation if you get an exception in setFoo(), WM 

> will blythely do something like:
>
> set("Foo", new Boolean(true));
>
> With the patch this would spew the RTE.  This seems more sensible to me, 

> it's possible some applications rely on this behavior.

Personally this sounds a bit crazy to me. What is the reasoning, if any, 
for WM to keep trying other setters compatible with the types being used?

This can have all kinds of weird repercussions, like half-completed "set" 
mechanisms that throw an exception and then it rolls onto another one to 
do 
more damage.

This seems like very bad logic to me. If an exception occurs using a 
compatible setter, it should be assumed that the value is bad or there is 
a 
bug, and the code shoud jump out and spew the exception.

Hiding the error and carrying on to see if any other setters work is... a 
little screwy - and could be hiding obscure bugs!

Anyone know if it is it there for a specific reason?

Marc



-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel