Don't think so, your case is due to 2 wrappings: one for the run() method and one for the postconstruct and both unwrap once it seems
opened https://issues.apache.org/jira/browse/OWB-1303 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 4 déc. 2019 à 12:41, Barjenbruch, Kjel <[email protected]> a écrit : > Hi, > > > > I do understand that rational. But why is the user code exception also > unwrapped? > > > > The provided stacktrace is one of the following scenario: > > We do have a class BatchItemLayoutRepository which accesses an > LayoutRepository#getLayout(Path) method. That method accesses a map which > is filled in the post construct. In case a layout file cannot be read a > NullPointerException is thrown which we wrap in our own exception an > RuntimeErrorCodeException. The access of the method returns the > NullPointerException instead oft he wrapping exception, which is an issue > for us since the wrapping exception holds the actual useful information > about what exactly happened (which is now lost). I would expect OWB to > only unwrap its own exceptions but not the user code exceptions. > > The provided code example displays this exact issue. One would expect that > the Exception caught and logged in MainRunnable would be the wrapping > RuntimeException which is thrown in the PostConstruct of the > ThrowingRepository. But instead the encased NullPointerException is caught > and logged. > > > > Is this behaviour really intended? > > > > *Von:* Romain Manni-Bucau <[email protected]> > *Gesendet:* Mittwoch, 4. Dezember 2019 11:26 > *An:* [email protected] > *Betreff:* Re: OWB Unwrapping of root cause for PostConstruct exceptions > > > > Hi, > > > > the rational of such unwrapping is to hide the reflection which does not > help to understand the cause so we try to only log the user code exception > > > > Hope it makes sense > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > > > > Le mer. 4 déc. 2019 à 10:34, Barjenbruch, Kjel <[email protected]> > a écrit : > > (One should end an e-mail before sending it.) > > Hi again and back to the question. > > We use OWB for our Java SE Applications and ran into an issue: We > sometimes do throw RuntimeExceptions out of inialization methods annoted > with @PostConstruct. > > As part of our error handling we do log those exceptions. The issue we are > facing is that the the exceptions root cause is unwrapped by OWB and thrown > instead of the original Exception, which causes a loss of information. > > > > My questions are : > > 1. For what reason is the root cause unwrapped? > 2. Is there a simple workaround for this? > > > > More information is provided below. > > > > Best wishes > > Kjel Barjenbruch > > > > > > The part of code responsible for this is implemented in > AbstractOwbBean#getRootException method. > > > > The stacktrace oft he unwrapping looks like this (i added a breakpoint in > #getCause oft he exception to trace this): > > Daemon Thread [core-0] (Suspended (breakpoint at line 104 in > RuntimeErrorCodeException)) > > RuntimeErrorCodeException.getCause() line: 104 > > ManagedBean<T>(AbstractOwbBean<T>).getRootException(Throwable) > line: 151 > > ManagedBean<T>(AbstractOwbBean<T>).create(CreationalContext<T>) > line: 137 > > ManagedBean<T>.create(CreationalContext<T>) line: 67 > > BeanInstanceBag<T>.create(Contextual<T>) line: 76 > > CoreContext(AbstractContext).getInstance(Contextual<T>, > CreationalContext<T>) line: 159 > > CoreContext(AbstractContext).get(Contextual<T>, > CreationalContext<T>) line: 125 > > NormalScopedBeanInterceptorHandler.getContextualInstance() line: > 101 > > NormalScopedBeanInterceptorHandler.get() line: 71 > > LayoutRepository$$OwbNormalScopeProxy0.getLayout(Path) line: not > available > > BatchItemLayoutRepository.init() line: 30 > > ... (shortened for readability) > > > > A simple Example would consist oft he following classe: > > > > -- Class using the repository which throws an exception in it’s post > construct: -- > > import javax.enterprise.context.ApplicationScoped; > > import javax.inject.Inject; > > > > @ApplicationScoped > > public class ClassUsingThrowingRepository { > > > > @Inject > > ThrowingRepository repo; > > > > public Object get() { > > return repo.get(); > > } > > > > } > > > > -- Repository implementation which throws the exception: > > import javax.annotation.PostConstruct; > > import javax.enterprise.context.ApplicationScoped; > > > > @ApplicationScoped > > public class ThrowingRepository { > > > > private Object fancyObjectWhichNeverSeesTheLightOfDay; > > > > @PostConstruct > > void init() { > > fancyObjectWhichNeverSeesTheLightOfDay = getFancyObject(); > > } > > > > private Object getFancyObject() { > > throw new RuntimeException( > > "Wrapping cause.", > > new NullPointerException("Null pointer exception in > initilization of throwing repo.")); > > } > > > > public Object get() { > > return fancyObjectWhichNeverSeesTheLightOfDay; > > } > > > > } > > -- Runnable which accesses the get method: > > import javax.enterprise.context.ApplicationScoped; > > import javax.inject.Inject; > > > > @ApplicationScoped > > public class MainRunnable implements Runnable { > > > > @Inject > > RepositoryUsingClass repoUsingClass; > > > > @Override > > public void run() { > > try { > > repoUsingClass.get(); > > } catch (final RuntimeException exc) { > > LOGGER.error("Caught exception.", exc); > > } > > } > > > > } > > > > *Von:* Barjenbruch, Kjel > *Gesendet:* Mittwoch, 4. Dezember 2019 10:17 > *An:* '[email protected]' <[email protected]> > *Betreff:* OWB Unwrapping of root cause for PostConstruct exceptions > > > > Hello, > > We use OWB for our Java SE Applications and ran into an issue: We > sometimes do throw RuntimeExceptions out of inialization methods > > > > > > CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg > HR B 208214; Persönlich haftende geschäftsführende und > vertretungsberechtigte Gesellschafterin: > Neumüller CEWE COLOR Stiftung, Sitz: Oldenburg; > Stiftungsverzeichnis der rechtsfähigen Stiftungen des bürgerlichen Rechts > im Bezirk der Regierungsvertretung Oldenburg Nummer 15(034). > *Stiftungsvorstand: * > Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner > Fageth, Carsten Heitkamp, Dr. Olaf Holzkämper, Thomas Mehls, Frank Zweigle > *Aufsichtsrat: * > Otto Korte (Vorsitzender) > UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4 > > > > CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg > HR B 208214; Persönlich haftende geschäftsführende und > vertretungsberechtigte Gesellschafterin: > Neumüller CEWE COLOR Stiftung, Sitz: Oldenburg; > Stiftungsverzeichnis der rechtsfähigen Stiftungen des bürgerlichen Rechts > im Bezirk der Regierungsvertretung Oldenburg Nummer 15(034). > *Stiftungsvorstand: * > Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner > Fageth, Carsten Heitkamp, Dr. Olaf Holzkämper, Thomas Mehls, Frank Zweigle > *Aufsichtsrat: * > Otto Korte (Vorsitzender) > UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4 >
