I would say this change should be reverted in GWT then. Personally I would
never ever delete any already emulated class in GWT.
While this exception has been misused in some of the above code (e.g.
URL.openStream() should not be emulated at all or throw
UnsupportedOperationException), in the em
Thanks for the heads up - it was removed since it isn't possible to throw
in client code anyway, and projects could emulate it themselves if
necessary. I'm curious about why gwt-bean-validators must have it, as the
original validator code did not have it - is it expecting it to be possible
to t
I believe that the reason this class existed to begin with was to allow
(for some reason..) RPC to serialize that exception and pass it to client
code. But emulation that "needs" it to match the correct signature can
safely remove it from a "throws" clause without breaking the contract,
correct
It is not a RuntimeException so even though you might be able to remove it
from GWT emulation code, your IDE will still annoy you in calling code to
either catch that exception or redeclare it because your IDE does not know
that GWT emul is cheating. If that calling code is exclusively within ot
> It has always had a private constructor to make that completely
> impossible.
>
Private constructor? Looks like it always was public as it should.
https://github.com/gwtproject/gwt/blob/2.8.2/user/super/com/google/gwt/emul/java/lang/NoSuchMethodException.java
-- J.
--
You received this
I agree this is mostly a misuse like you said. We don't have any internal
usage in all Google either so I would rather push users to not
declare/catch such exceptions. Keeping such classes opens the door for
more: https://gwt-review.googlesource.com/c/gwt/+/21320
I think IDE warnings in couple of c
Hi together,
the original validation code has no reflection emulation for accessing getters.
In gwt-bean-validators you can simply use
org.apache.commons.beanutils.PropertyUtils.getProperty(Object, String) and
org.apache.commons.beanutils.BeanUtils.getProperty(Object, String) which both
throw
> I agree this is mostly a misuse like you said. We don't have any internal
> usage in all Google either so I would rather push users to not
> declare/catch such exceptions. Keeping such classes opens the door for
> more: https://gwt-review.googlesource.com/c/gwt/+/21320
>
Actually I am total
It is not a problem of a single class by itself. It is a problem of policy
and opening the gate for much more. Without a good justification to make an
exception in the policy, we get bombarded with emulation requests (most you
don't even see) that have zero or very little value. Inconsistency doesn
For me (and gwt-bean validators) it doesn't matter if I include
NoSuchMethodException myself or if it's part of gwt. I only have to know, how
to handle it for next release.
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe fro
10 matches
Mail list logo
