Re: [Webmacro-devel] Incorrect exception reporting

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

What's happening here is that an exception is getting thrown, but the=20
DefaultEEH ignores it during eval and just returns null.  So your=20
expression becomes

#if (null > 0){

A "not comparable" exception makes a bit more sense in this context.  We=20
could probably improve this to say "Cannot compare null to an Integer" or=20
something.

The good news is that a more informative message gets logged, and of=20
course you can use a stricter EEH.

Keats



This is totally unrelated I'm sure, but it's another incorrect=20
exception I noticed today.

#if ($document.PageCount > 0) {
                 do stuff
}

where .PageCount is:
                 public int getPageCount();

The exception I got was:
                 Objects not comparable

It turned out that $document was null.  So shouldn't WM have said=20
something like "$document is null.  Cannot access .PageCount"?

eric

On Tuesday, May 27, 2003, at 02:22  PM, Keats=5FK...@di...=20
wrote:

>
> I agree totally. =A0I'm just trying to tread lightly and reduce the=20
> possibilities for regression errors. =A0I don't know if there is any=20
> reason why we would want to continue after an exception, but=20
> 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(),=20
> line 1185.
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/=20
> org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-=20
> type=3Dtext/vnd.viewcvs-markup
>
> Keats
>
>
>
> On Tue, 27 May 2003 12:48:05 -0400, <Keats=5FK...@di...> wrote:
>
> > I've tracked this down and patched it locally, but I need to do a=20
> bit of
> > regression testing before I commit it.
>
> Great work!
>
> > The problem is a bit esoteric. =A0It has to do with the fact that=20
> there can
> > be multiple "set" methods for a primitive type. =A0The PropertyOperator
> > just tries them all until one works, ignoring any exceptions along=20
> the
> > way. =A0So if you hit an exception in a primitive "set" operation, WM=20
> acts
> > as if there was no appropriate method found -- hence the misleading=20
> error
> > message.
> >
> > My patch just saves the exception and rethrows it if none of the=20
> "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=20
> "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=3Dtrue
> >
> > Under the current implementation if you get an exception in=20
> setFoo(), WM
> > will blythely do something like:
> >
> > set("Foo", new Boolean(true));
> >
> > With the patch this would spew the RTE. =A0This 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=20
> any,
> for WM to keep trying other setters compatible with the types being=20
> used?
>
> This can have all kinds of weird repercussions, like half-completed=20
> "set"
> mechanisms that throw an exception and then it rolls onto another one=20
> 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=20
> 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=20
> 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
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>



-------------------------------------------------------
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
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel