You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by Tom Barber <to...@meteorite.bi> on 2015/10/26 23:36:45 UTC
Preserving the stack trace
First up apologies for anyone who had to merge my work from the weekend, I
did it then in the hope it didn't effect anyone too much, on the bright
side we did remove about 200 "days" of technical debt from Sonar, only 1200
to go......
Anyway!
Here's one for you guys,
https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false|severities=MAJOR|rules=pmd%3APreserveStackTrace
Now I may not have been around in the Java world for as long as some people
but we are catching exceptions all over the place and masking the true
cause..... can anyone explain why?
>From my perspective its bad practice even without Sonar telling me, IBM
also seems to agree:
http://www-01.ibm.com/support/docview.wss?uid=swg21386753
We have enough issues debugging random errors as it is, munging the
exception into another exception seems a bit crazy to me.
Tom
Re: Preserving the stack trace
Posted by Tom Barber <to...@meteorite.bi>.
Good enough answer for me thanks boss.
i was thinking in a few months once we've based through the majority of
these issues (I hope) we should look at some code control, I've not come
across forbidden apis but it looks similar to checkstyle at a glance, so
something to try and keep code quality up instead of having to do it all
over again would, in my opinion, be useful, considering the size and
modularity of the codebase.
Tom
On Tue, Oct 27, 2015 at 3:40 AM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:
> Hi Tom,
> I would say is that we could add the forbidden API's plugin as well.
> https://github.com/policeman-tools/forbidden-apis
> I'll log this as a Jira ticket as it makes many of these checks whenever
> the code is built so would be good to have.
> I've checked some of the rule infringements you've stated from Sonar and I
> agree that we should be addressing them. It may not even have been obvious
> to people when they were coding this up in the past that they were not
> properly handing error checking. If no automated static code analysis was
> going on then this may have just been oversight.
> Lets start hammering some of the issues. Can do it class-by-class,
> module-by-module or whatever.
> Lewis
>
> On Mon, Oct 26, 2015 at 4:50 PM, Tom Barber <to...@meteorite.bi>
> wrote:
>
> > Sorry should just clarify, reworking it into a different exception I have
> > no issue with, dropping the root cause is troublesome though.
> >
> > On Mon, Oct 26, 2015 at 10:36 PM, Tom Barber <to...@meteorite.bi>
> > wrote:
> >
> > > First up apologies for anyone who had to merge my work from the
> weekend,
> > I
> > > did it then in the hope it didn't effect anyone too much, on the bright
> > > side we did remove about 200 "days" of technical debt from Sonar, only
> > 1200
> > > to go......
> > >
> > >
> > > Anyway!
> > >
> > > Here's one for you guys,
> > >
> > >
> > >
> >
> https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false|severities=MAJOR|rules=pmd%3APreserveStackTrace
> > > <
> >
> https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false%7Cseverities=MAJOR%7Crules=pmd%3APreserveStackTrace
> > >
> > >
> > > Now I may not have been around in the Java world for as long as some
> > > people but we are catching exceptions all over the place and masking
> the
> > > true cause..... can anyone explain why?
> > >
> > > From my perspective its bad practice even without Sonar telling me, IBM
> > > also seems to agree:
> > > http://www-01.ibm.com/support/docview.wss?uid=swg21386753
> > >
> > > We have enough issues debugging random errors as it is, munging the
> > > exception into another exception seems a bit crazy to me.
> > >
> > > Tom
> > >
> >
>
>
>
> --
> *Lewis*
>
Re: Preserving the stack trace
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Hi Tom,
I would say is that we could add the forbidden API's plugin as well.
https://github.com/policeman-tools/forbidden-apis
I'll log this as a Jira ticket as it makes many of these checks whenever
the code is built so would be good to have.
I've checked some of the rule infringements you've stated from Sonar and I
agree that we should be addressing them. It may not even have been obvious
to people when they were coding this up in the past that they were not
properly handing error checking. If no automated static code analysis was
going on then this may have just been oversight.
Lets start hammering some of the issues. Can do it class-by-class,
module-by-module or whatever.
Lewis
On Mon, Oct 26, 2015 at 4:50 PM, Tom Barber <to...@meteorite.bi> wrote:
> Sorry should just clarify, reworking it into a different exception I have
> no issue with, dropping the root cause is troublesome though.
>
> On Mon, Oct 26, 2015 at 10:36 PM, Tom Barber <to...@meteorite.bi>
> wrote:
>
> > First up apologies for anyone who had to merge my work from the weekend,
> I
> > did it then in the hope it didn't effect anyone too much, on the bright
> > side we did remove about 200 "days" of technical debt from Sonar, only
> 1200
> > to go......
> >
> >
> > Anyway!
> >
> > Here's one for you guys,
> >
> >
> >
> https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false|severities=MAJOR|rules=pmd%3APreserveStackTrace
> > <
> https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false%7Cseverities=MAJOR%7Crules=pmd%3APreserveStackTrace
> >
> >
> > Now I may not have been around in the Java world for as long as some
> > people but we are catching exceptions all over the place and masking the
> > true cause..... can anyone explain why?
> >
> > From my perspective its bad practice even without Sonar telling me, IBM
> > also seems to agree:
> > http://www-01.ibm.com/support/docview.wss?uid=swg21386753
> >
> > We have enough issues debugging random errors as it is, munging the
> > exception into another exception seems a bit crazy to me.
> >
> > Tom
> >
>
--
*Lewis*
Re: Preserving the stack trace
Posted by Tom Barber <to...@meteorite.bi>.
Sorry should just clarify, reworking it into a different exception I have
no issue with, dropping the root cause is troublesome though.
On Mon, Oct 26, 2015 at 10:36 PM, Tom Barber <to...@meteorite.bi>
wrote:
> First up apologies for anyone who had to merge my work from the weekend, I
> did it then in the hope it didn't effect anyone too much, on the bright
> side we did remove about 200 "days" of technical debt from Sonar, only 1200
> to go......
>
>
> Anyway!
>
> Here's one for you guys,
>
>
> https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false|severities=MAJOR|rules=pmd%3APreserveStackTrace
> <https://analysis.apache.org/component_issues?id=org.apache.oodt%3Aoodt#resolved=false%7Cseverities=MAJOR%7Crules=pmd%3APreserveStackTrace>
>
> Now I may not have been around in the Java world for as long as some
> people but we are catching exceptions all over the place and masking the
> true cause..... can anyone explain why?
>
> From my perspective its bad practice even without Sonar telling me, IBM
> also seems to agree:
> http://www-01.ibm.com/support/docview.wss?uid=swg21386753
>
> We have enough issues debugging random errors as it is, munging the
> exception into another exception seems a bit crazy to me.
>
> Tom
>