Re: [Webmacro-devel] Incorrect exception reporting

[Eric B. R. <eb...@tc...>]

On Tuesday, May 27, 2003, at 04:32  PM, Kea...@di...=20
wrote:

>
> What's happening here is that an exception is getting thrown, but the=20=

> DefaultEEH ignores it during eval and just returns null. =A0So your=20
> expression becomes
>
> #if (null > 0){
>
> A "not comparable" exception makes a bit more sense in this context.=20=

> =A0We could probably improve this to say "Cannot compare null to an=20
> Integer" or something.

$somethingThatIsNull.SomeProperty isn't null.  It won't evaluate in any=20=

other context...

eric

>
> 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 =A0
> exception I noticed today.
>
> #if ($document.PageCount > 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do stuff
> }
>
> where .PageCount is:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public int getPageCount();
>
> The exception I got was:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Objects not comparable
>
> It turned out that $document was null. =A0So shouldn't WM have said =A0
> something like "$document is null. =A0Cannot access .PageCount"?
>
> eric
>
> On Tuesday, May 27, 2003, at 02:22 =A0PM, Kea...@di... =A0=

> wrote:
>
> >
> > I agree totally. =A0I'm just trying to tread lightly and reduce the =
=A0
> > possibilities for regression errors. =A0I don't know if there is any =
=A0
> > reason why we would want to continue after an exception, but =A0
> > 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(), =
=A0
> > line 1185.
> >
> > =
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/
> > org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-
> > type=3Dtext/vnd.viewcvs-markup
> >
> > Keats
> >
> >
> >
> > On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...>=20
> wrote:
> >
> > > I've tracked this down and patched it locally, but I need to do a =
=A0
> > bit of
> > > regression testing before I commit it.
> >
> > Great work!
> >
> > > The problem is a bit esoteric. =A0It has to do with the fact that =
=A0
> > there can
> > > be multiple "set" methods for a primitive type. =A0The=20
> PropertyOperator
> > > just tries them all until one works, ignoring any exceptions along=20=

> =A0
> > the
> > > way. =A0So if you hit an exception in a primitive "set" operation,=20=

> WM =A0
> > acts
> > > as if there was no appropriate method found -- hence the=20
> misleading =A0
> > error
> > > message.
> > >
> > > My patch just saves the exception and rethrows it if none of the =A0=

> > "set"
> > > invocations were successful.
> >
> > Shouldn't "fail fast" be the real solution here? i.e. if any=20
> 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=20=

> a =A0
> > "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 =A0
> > setFoo(), WM
> > > will blythely do something like:
> > >
> > > set("Foo", new Boolean(true));
> > >
> > > With the patch this would spew the RTE. =A0This seems more =
sensible=20
> to =A0
> > me,
> > > it's possible some applications rely on this behavior.
> >
> > Personally this sounds a bit crazy to me. What is the reasoning, if =
=A0
> > any,
> > for WM to keep trying other setters compatible with the types being =
=A0
> > used?
> >
> > This can have all kinds of weird repercussions, like half-completed =
=A0
> > "set"
> > mechanisms that throw an exception and then it rolls onto another=20
> one =A0
> > 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=20
> there =A0
> > 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 =A0
> > 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
> >
> >
>
>
>
> -------------------------------------------------------
> 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
>
>