Hi, advantages are Guice shows: - where the offending constant was bound; - to what type it tried to convert it (not necessary the type that is required - can be subtype); - where the converter was bound.
I think this can be helpfull information :) 2013/3/30 Daniel Manzke <daniel.man...@googlemail.com> > Hi, > > I don't see any advantage from 2. But I'm not familiar with the test case > maybe I just don't get the point of the information which is not delivered > with 1 but in 2. > Could you explain it a little bit more? :) > > > Thx, > Daniel > > On Mar 30, 2013, at 9:45 AM, Mikhail Mazursky (JIRA) <j...@apache.org> > wrote: > > > > > [ > https://issues.apache.org/jira/browse/ONAMI-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618021#comment-13618021] > > > > Mikhail Mazursky commented on ONAMI-88: > > --------------------------------------- > > > > I experimented a bit with catching RuntimeException and wrapping it in > ProvisionException vs just letting exception propagate. I used existing > code in UUIDConverter as a testcase. So, the current behaviour (catch&wrap) > results in this output (i obused a test in other project for experiments - > don't take it into account): > > > > com.google.inject.ConfigurationException: Guice configuration errors: > > > > 1) String value 'abcasd' is not a valid UUID > > while locating java.util.UUID annotated with > @com.google.inject.name.Named(value=a) > > for field at > org.apache.onami.converters.net.URLConverterTestCase.u(URLConverterTestCase.java:43) > > while locating org.apache.onami.converters.net.URLConverterTestCase > > > > 1 error > > at > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1004) > > [...] > > Caused by: java.lang.IllegalArgumentException: Invalid UUID string: > abcasd > > at java.util.UUID.fromString(UUID.java:194) > > [...] > > > > If we don't catch - this is the output: > > > > com.google.inject.ConfigurationException: Guice configuration errors: > > > > 1) Error converting 'abcasd' (bound at > org.apache.onami.converters.net.URLConverterTestCase$1.configure(URLConverterTestCase.java:54)) > to java.util.UUID > > using java.util.UUID which matches only(java.util.UUID) (bound at > org.apache.onami.converters.core.AbstractConverter.configure(AbstractConverter.java:44)). > > Reason: java.lang.IllegalArgumentException: Invalid UUID string: abcasd > > while locating java.util.UUID annotated with > @com.google.inject.name.Named(value=a) > > for field at > org.apache.onami.converters.net.URLConverterTestCase.u(URLConverterTestCase.java:43) > > while locating org.apache.onami.converters.net.URLConverterTestCase > > > > 1 error > > at > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1004) > > [...] > > Caused by: java.lang.IllegalArgumentException: Invalid UUID string: > abcasd > > at java.util.UUID.fromString(UUID.java:194) > > [...] > > > > As you can see, wrapping in ProvisionException gives us less information > - apparently Guice treats ProvisionException somehow not like other > exceptions. I propose to get rid of wrapping in ProvisionException and wrap > only checked exceptions in RuntimeException where necessary. WDYT? > > > >> Consistent policy for exception handling > >> ---------------------------------------- > >> > >> Key: ONAMI-88 > >> URL: https://issues.apache.org/jira/browse/ONAMI-88 > >> Project: Apache Onami > >> Issue Type: Improvement > >> Components: configuration > >> Affects Versions: configuration-6.3.0 > >> Reporter: Mikhail Mazursky > >> Priority: Minor > >> > >> No consistent policy for exception handling - for example > SQLTimestampConverter catches Throwable and rethrows it as > ProvisionException but CharsetConverter do not catch anything at all. > Should we catch at all or Guice handles this itself? > >> I guess we should rethrow only checked exceptions. Also no need to > catch Errors in such places in any case (catch Exception vs Throwable). > > > > -- > > This message is automatically generated by JIRA. > > If you think it was sent incorrectly, please contact your JIRA > administrators > > For more information on JIRA, see: > http://www.atlassian.com/software/jira > >