What was wrong with the idea of a try catch block at the producer level? Sent from my iPhone
On Jun 14, 2012, at 19:17, Gerhard Petracek <[email protected]> wrote: > it isn't about recovering from it. > it's about the approach we suggest/support to handle it with a custom > implementation (since there are a lot of different requirements out there). > > e.g. > //... > public class MyBean > { > @Inject > @ConfigProperty(name = "myProperty") > private Integer myProperty; > > public Integer getMyProperty() > { > return myProperty; > } > } > > in case of an invalid value the producer for this config-property (provided > by deltaspike) will throw a NumberFormatException (after a recent commit > from mark a generic RuntimeException which wraps it). > since the @ConfigProperty-producers create >dependent scoped< values, the > exception can be caused by any method-call to this bean (even by e.g. > #toString), because those producers get called at the first method-call to > the bean. > -> you can't use a simple try/catch block only for #getMyProperty to > integrate a custom/special implementation for handling exceptions thrown by > a @ConfigProperty-producer (as mentioned earlier: i'm not talking > about recovering from it) . > > for integrating a custom implementation for handling it, there are the > following possibilities: > > - throwing a generic RuntimeException with the available information > (that's what was added during this discussion) > - throwing a custom RuntimeException with the available information > - integrating with the exception handler of deltaspike (qualification of > the exception) > - some other possibilities which aren't that nice at all > > bootstrapping is always a special case - the main part is how we handle > such topics at runtime (after the bootstrapping process). > since @ConfigProperty is important and quite special at the same time and > the producers are called after the bootstrapping process, we can use it as > a first example for the whole topic (of using the exception handler of > deltaspike internally). > > regards, > gerhard > > > > 2012/6/14 Mark Struberg <[email protected]> > >> Well, this is split. The native underlying impl is already being used >> during bootstrap by Extensions. >> The injection stuff can of course only be performed after the container >> did finally boot. >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Gerhard Petracek <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Thursday, June 14, 2012 11:23 PM >>> Subject: Re: git commit: DELTASPIKE-196 NO integration with Exception >> Handler needed! >>> >>> right now we don't do it during the bootstrapping process (it's done >>> lazily >>> during runtime). >>> >>> the basic question is where and how we integrate our own exception >> handling >>> mechanism in the rest of deltaspike. >>> and i think jason is the expert for it since he wrote the catch module. >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2012/6/14 Jason Porter <[email protected]> >>> >>>> Gerhard asked me to take a look at this, and I didn't have the full >>> context >>>> on IRC. In speaking with him it sounded like a good idea to use the DS >>>> exception handling here, however, Mark makes an excellent point about >> not >>>> really being able to solve this without user intervention. We could use >>>> exception handling here and if there isn't any thing to handle it, we >>> could >>>> rethrow the exception and halt the deployment anyway. >>>> >>>> Another thought just occurred to me, because we're really doing this >>> before >>>> the application fully completes deployment, I'm not even 100% sure >>>> DeltaSpike exception handling would work, that's probably an >>> implementation >>>> specific detail. In light of those two ideas, I'm going to stand by >>> Mark >>>> and say we should leave it out. >>>> >>>> On Thu, Jun 14, 2012 at 12:26 AM, <[email protected]> wrote: >>>> >>>>> Updated Branches: >>>>> refs/heads/master 9ca1855d7 -> 1c6354650 >>>>> >>>>> >>>>> DELTASPIKE-196 NO integration with Exception Handler needed! >>>>> >>>>> The DS Exception Handler is for _business_ methods. >>>>> Technical and configuration issues shall not be handled by DS >>>>> but by the user. We cannot recover from it without any >>>>> user interaction anyway... >>>>> >>>>> >>>>> Project: >>>> http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo >>>>> Commit: >>>>> >>>> >> http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/1c635465 >>>>> Tree: >>>>> >>>> >> http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/1c635465 >>>>> Diff: >>>>> >>>> >> http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/1c635465 >>>>> >>>>> Branch: refs/heads/master >>>>> Commit: 1c63546506457e1a74fed6ca92cb9d0c0d54a2fc >>>>> Parents: 9ca1855 >>>>> Author: Mark Struberg <[email protected]> >>>>> Authored: Thu Jun 14 07:55:52 2012 +0200 >>>>> Committer: Mark Struberg <[email protected]> >>>>> Committed: Thu Jun 14 07:55:52 2012 +0200 >>>>> >>>>> >> ---------------------------------------------------------------------- >>>>> .../impl/config/DefaultConfigPropertyProducer.java | 3 --- >>>>> 1 files changed, 0 insertions(+), 3 deletions(-) >>>>> >> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>> >>> >> http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/1c635465/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java >>>>> >> ---------------------------------------------------------------------- >>>>> diff --git >>>>> >>>> >>> >> a/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java >>>>> >>>> >>> >> b/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java >>>>> index d878139..cd4422e 100644 >>>>> --- >>>>> >>>> >>> >> a/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java >>>>> +++ >>>>> >>>> >>> >> b/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/DefaultConfigPropertyProducer.java >>>>> @@ -54,7 +54,6 @@ public class DefaultConfigPropertyProducer extends >>>>> BaseConfigPropertyProducer >>>>> return null; >>>>> } >>>>> >>>>> - //X TODO integrate with the HandledHandler of DeltaSpike >>>>> return Integer.parseInt(configuredValue); >>>>> } >>>>> >>>>> @@ -69,7 +68,6 @@ public class DefaultConfigPropertyProducer extends >>>>> BaseConfigPropertyProducer >>>>> return null; >>>>> } >>>>> >>>>> - //X TODO integrate with the HandledHandler of DeltaSpike >>>>> return Long.parseLong(configuredValue); >>>>> } >>>>> >>>>> @@ -108,7 +106,6 @@ public class DefaultConfigPropertyProducer >> extends >>>>> BaseConfigPropertyProducer >>>>> } >>>>> >>>>> //X TODO think about something like @NumberFormat(...) >>>>> - //X TODO integrate with the HandledHandler of DeltaSpike >>>>> return Float.parseFloat(configuredValue); >>>>> } >>>>> } >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jason Porter >>>> http://lightguard-jp.blogspot.com >>>> http://twitter.com/lightguardjp >>>> >>>> Software Engineer >>>> Open Source Advocate >>>> Author of Seam Catch - Next Generation Java Exception Handling >>>> >>>> PGP key id: 926CCFF5 >>>> PGP key available at: keyserver.net, pgp.mit.edu >>>> >>> >>
