1:59 p.m.
Based on current implementation, the following methods I think should
throw a exception, something like:
ResourceNotFoundException
org.drools.compiler.PackageBuilder.addKnowledgeResource()
org.drools.builder.impl.KnowledgeBuilderImpl.add()
another option might be to verify the validity of a Resource object at
creation time and make ResourceFactory factory methods throw
ResourceNotFoundException.
I believe the case of a "not found resource" the user of the api should
be "ecouraged" to handle.
Another case that might be needed to be handled could be
InvalidResource?
Let me know what you guys think
Regards
--zoly
7:03 p.m.
Zoltan Farkas wrote:
Based on current implementation, the following methods I think should
throw a exception, something like:
ResourceNotFoundException
do you want this as runtime or catched exception? At the
moment we are
trying to avoid catched exceptions.
Mark
org.drools.compiler.PackageBuilder.addKnowledgeResource()
org.drools.builder.impl.KnowledgeBuilderImpl.add()
another option might be to verify the validity of a Resource object at
creation time and make ResourceFactory factory methods throw
ResourceNotFoundException.
I believe the case of a "not found resource" the user of the api
should be "ecouraged" to handle.
Another case that might be needed to be handled could be InvalidResource?
Let me know what you guys think
Regards
--zoly
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:10 a.m.
From my point of view as a developer who writes code against the api,
I have to handle to case of a Resource not being there, or being
invalid/corupt... theese are casses that I need to recover from in my
code...
and I have no way of knowing what do I need to catch and where, without
first writing the code, run tests against it, and examine stack traces.
I find this quite inefficient...
If you google for ResourceNotFoundException, you will find out that
there is quite a few APIs out there that implement it. There is other
apis that have InvalidResourceException... or
javx.resource.ResourceException
My preference would be toward catched Exceptions in this case.
--zoly
________________________________
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: Thursday, December 11, 2008 8:04 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools API improvement sugestion
Zoltan Farkas wrote:
Based on current implementation, the following methods I think
should throw a exception, something like:
ResourceNotFoundException
do you want this as runtime or catched exception? At the moment we are
trying to avoid catched exceptions.
Mark
org.drools.compiler.PackageBuilder.addKnowledgeResource()
org.drools.builder.impl.KnowledgeBuilderImpl.add()
another option might be to verify the validity of a Resource
object at creation time and make ResourceFactory factory methods throw
ResourceNotFoundException.
I believe the case of a "not found resource" the user of the api
should be "ecouraged" to handle.
Another case that might be needed to be handled could be
InvalidResource?
Let me know what you guys think
Regards
--zoly
________________________________
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:30 a.m.
I vote for runtime exception. That gives you the option of catching it or not. Just from
experience I can't tell you how nice it was when HibernateException went from a
checked to an unchecked exception.
That being said, the API methods that can throw it should still declare it in the throws
clause, even if it's a runtime exception. That helps IDEs like Eclipse wrap method
calls in the right try/catch blocks when generating code. (See the
"Source->Surround With->try/catch block" menu option)
--- On Fri, 12/12/08, Zoltan Farkas <zoly(a)daxtechnologies.com> wrote:
From: Zoltan Farkas <zoly(a)daxtechnologies.com>
Subject: RE: [rules-dev] Drools API improvement sugestion
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Date: Friday, December 12, 2008, 10:10 AM
>From my point of view as a developer who writes code
against the api,
I have to handle to case of a Resource not being there, or
being
invalid/corupt... theese are casses that I need to recover
from in my
code...
and I have no way of knowing what do I need to catch and
where, without
first writing the code, run tests against it, and examine
stack traces.
I find this quite inefficient...
If you google for ResourceNotFoundException, you will find
out that
there is quite a few APIs out there that implement it.
There is other
apis that have InvalidResourceException... or
javx.resource.ResourceException
My preference would be toward catched Exceptions in this
case.
--zoly
________________________________
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of
Mark Proctor
Sent: Thursday, December 11, 2008 8:04 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools API improvement sugestion
Zoltan Farkas wrote:
Based on current implementation, the following methods I
think
should throw a exception, something like:
ResourceNotFoundException
do you want this as runtime or catched exception? At the
moment we are
trying to avoid catched exceptions.
Mark
org.drools.compiler.PackageBuilder.addKnowledgeResource()
org.drools.builder.impl.KnowledgeBuilderImpl.add()
another option might be to verify the validity of a
Resource
object at creation time and make ResourceFactory factory
methods throw
ResourceNotFoundException.
I believe the case of a "not found resource" the
user of the api
should be "ecouraged" to handle.
Another case that might be needed to be handled could be
InvalidResource?
Let me know what you guys think
Regards
--zoly
________________________________
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:15 a.m.
Greetings:
Not too often do I get personally involved in Java/J2EE disputes among
those who are virtually experts at this game. However, exceptions is
one of my pet peeves. NOT catching an exception shows a bit of
disregard for the integrity of the product itself and, IMHO,
everything should be in a try / catch block such that the exception is
NOT caught only in trivial circumstances. (And if it's so trivial
that it doesn't need a try/catch block, is it necessary at all?)
As an old C programmer (yes, there are still a few of us around) if we
thought that we were really, really good programmers we would run
"lint" on our program before sending it to QA. And QA always ran
"lint" just for the fun of showing up our poor programming. It was
usually an humbling experience. Catching all of the exceptions during
testing should be required. Catching all of the exceptions during run
time is debatable. I would think that NOT catching exceptions is what
makes for run time problems that could have been caught during compile/
design time.
The final question is WHAT to do with a caught exception? This is
where experience shows up and with some you can just toss an error
statement in a log somewhere with a warning. Others require an error
routine and stopping the program. Then that becomes a matter of
judgement. Catch and release? Nahhh... I only fish to eat, not for
sport. :-)
Just two cents.
SDG
James Owen
Senior Consultant / Architect
817.656.4553 office
214.684.5272 cell
Founder KnowledgeBased Systems Corporation
http://www.kbsc.com
Founder October Rules Fest
http://www.OctoberRulesFest.org
Blogs:
http://JavaRules.blogspot.com [Java-Oriented Rulebased Systems]
http://ORF2009.blogspot.com [October Rules Fest]
http://exscg.blogspot.com/ [Expert Systems Consulting Group]
"This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man."
Hamlet, Act 1, Scene III
http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
I vote for runtime exception. That gives you the option of catching
it or not. Just from experience I can't tell you how nice it was
when HibernateException went from a checked to an unchecked exception.
That being said, the API methods that can throw it should still
declare it in the throws clause, even if it's a runtime exception.
That helps IDEs like Eclipse wrap method calls in the right try/
catch blocks when generating code. (See the "Source->Surround With-
>try/catch block" menu option)
--- On Fri, 12/12/08, Zoltan Farkas <zoly(a)daxtechnologies.com> wrote:
> From: Zoltan Farkas <zoly(a)daxtechnologies.com>
> Subject: RE: [rules-dev] Drools API improvement sugestion
> To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
> Date: Friday, December 12, 2008, 10:10 AM
>> From my point of view as a developer who writes code
> against the api,
> I have to handle to case of a Resource not being there, or
> being
> invalid/corupt... theese are casses that I need to recover
> from in my
> code...
> and I have no way of knowing what do I need to catch and
> where, without
> first writing the code, run tests against it, and examine
> stack traces.
> I find this quite inefficient...
>
> If you google for ResourceNotFoundException, you will find
> out that
> there is quite a few APIs out there that implement it.
> There is other
> apis that have InvalidResourceException... or
> javx.resource.ResourceException
>
> My preference would be toward catched Exceptions in this
> case.
>
> --zoly
>
>
> ________________________________
>
> From: rules-dev-bounces(a)lists.jboss.org
> [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of
> Mark Proctor
> Sent: Thursday, December 11, 2008 8:04 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Drools API improvement sugestion
>
>
> Zoltan Farkas wrote:
>
> Based on current implementation, the following methods I
> think
> should throw a exception, something like:
> ResourceNotFoundException
>
> do you want this as runtime or catched exception? At the
> moment we are
> trying to avoid catched exceptions.
>
> Mark
>
>
>
> org.drools.compiler.PackageBuilder.addKnowledgeResource()
> org.drools.builder.impl.KnowledgeBuilderImpl.add()
>
> another option might be to verify the validity of a
> Resource
> object at creation time and make ResourceFactory factory
> methods throw
> ResourceNotFoundException.
>
> I believe the case of a "not found resource" the
> user of the api
> should be "ecouraged" to handle.
>
> Another case that might be needed to be handled could be
> InvalidResource?
>
> Let me know what you guys think
>
> Regards
>
> --zoly
>
> ________________________________
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:53 a.m.
I dunno, man. Do you catch every NullPointerException or ArrayIndexOutOfBoundsException
you could? I'm thinking not.
Yes, exceptions should be caught whenever possible, but forcing that on the programmer too
much can lead to this kind of pattern:
try {
...
} catch(OverusedAndThusAnnoyingCheckedException e) {}
This is CONCENTRATED EVIL. :) See "Item 65: Don't ignore exceptions" in
Josh Bloch's "Effective Java." Heck just see all of chapter 9. :)
In fact, this leads me to Bloch's "Item 58: Use checked exceptions for
recoverable conditions and runtime exceptions for programming errors." It strikes me
that a resource being missing can often be a programming error (fat fingered resource
name) but can also be a recoverable communication error. (remote storage unavailable) I
still lean towards an unchecked exception, though, because more often than not the
resources in question will be loaded from jars in the classpath, and failure to load them
will me mostly due to programmer error.
--- On Fri, 12/12/08, James C. Owen <jco(a)kbsc.com> wrote:
From: James C. Owen <jco(a)kbsc.com>
Subject: Re: [rules-dev] Drools API improvement sugestion
To: "Greg Barton" <greg_barton(a)yahoo.com>, "Rules Dev List"
<rules-dev(a)lists.jboss.org>, zoly(a)daxtechnologies.com
Date: Friday, December 12, 2008, 11:15 AM
Greetings:
Not too often do I get personally involved in Java/J2EE
disputes among
those who are virtually experts at this game. However,
exceptions is
one of my pet peeves. NOT catching an exception shows a
bit of
disregard for the integrity of the product itself and,
IMHO,
everything should be in a try / catch block such that the
exception is
NOT caught only in trivial circumstances. (And if it's
so trivial
that it doesn't need a try/catch block, is it necessary
at all?)
As an old C programmer (yes, there are still a few of us
around) if we
thought that we were really, really good programmers we
would run
"lint" on our program before sending it to QA.
And QA always ran
"lint" just for the fun of showing up our poor
programming. It was
usually an humbling experience. Catching all of the
exceptions during
testing should be required. Catching all of the exceptions
during run
time is debatable. I would think that NOT catching
exceptions is what
makes for run time problems that could have been caught
during compile/
design time.
The final question is WHAT to do with a caught exception?
This is
where experience shows up and with some you can just toss
an error
statement in a log somewhere with a warning. Others
require an error
routine and stopping the program. Then that becomes a
matter of
judgement. Catch and release? Nahhh... I only fish to
eat, not for
sport. :-)
Just two cents.
SDG
James Owen
Senior Consultant / Architect
817.656.4553 office
214.684.5272 cell
Founder KnowledgeBased Systems Corporation
http://www.kbsc.com
Founder October Rules Fest
http://www.OctoberRulesFest.org
Blogs:
http://JavaRules.blogspot.com [Java-Oriented Rulebased
Systems]
http://ORF2009.blogspot.com [October Rules Fest]
http://exscg.blogspot.com/ [Expert Systems Consulting
Group]
"This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man."
Hamlet, Act 1, Scene III
http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
> I vote for runtime exception. That gives you the
option of catching
> it or not. Just from experience I can't tell you
how nice it was
> when HibernateException went from a checked to an
unchecked exception.
>
> That being said, the API methods that can throw it
should still
> declare it in the throws clause, even if it's a
runtime exception.
> That helps IDEs like Eclipse wrap method calls in the
right try/
> catch blocks when generating code. (See the
"Source->Surround With-
> >try/catch block" menu option)
>
> --- On Fri, 12/12/08, Zoltan Farkas
<zoly(a)daxtechnologies.com> wrote:
>
>> From: Zoltan Farkas
<zoly(a)daxtechnologies.com>
>> Subject: RE: [rules-dev] Drools API improvement
sugestion
>> To: "Rules Dev List"
<rules-dev(a)lists.jboss.org>
>> Date: Friday, December 12, 2008, 10:10 AM
>>> From my point of view as a developer who
writes code
>> against the api,
>> I have to handle to case of a Resource not being
there, or
>> being
>> invalid/corupt... theese are casses that I need to
recover
>> from in my
>> code...
>> and I have no way of knowing what do I need to
catch and
>> where, without
>> first writing the code, run tests against it, and
examine
>> stack traces.
>> I find this quite inefficient...
>>
>> If you google for ResourceNotFoundException, you
will find
>> out that
>> there is quite a few APIs out there that implement
it.
>> There is other
>> apis that have InvalidResourceException... or
>> javx.resource.ResourceException
>>
>> My preference would be toward catched Exceptions
in this
>> case.
>>
>> --zoly
>>
>>
>> ________________________________
>>
>> From: rules-dev-bounces(a)lists.jboss.org
>> [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of
>> Mark Proctor
>> Sent: Thursday, December 11, 2008 8:04 PM
>> To: Rules Dev List
>> Subject: Re: [rules-dev] Drools API improvement
sugestion
>>
>>
>> Zoltan Farkas wrote:
>>
>> Based on current implementation, the following
methods I
>> think
>> should throw a exception, something like:
>> ResourceNotFoundException
>>
>> do you want this as runtime or catched exception?
At the
>> moment we are
>> trying to avoid catched exceptions.
>>
>> Mark
>>
>>
>>
>>
org.drools.compiler.PackageBuilder.addKnowledgeResource()
>>
org.drools.builder.impl.KnowledgeBuilderImpl.add()
>>
>> another option might be to verify the validity of
a
>> Resource
>> object at creation time and make ResourceFactory
factory
>> methods throw
>> ResourceNotFoundException.
>>
>> I believe the case of a "not found
resource" the
>> user of the api
>> should be "ecouraged" to handle.
>>
>> Another case that might be needed to be handled
could be
>> InvalidResource?
>>
>> Let me know what you guys think
>>
>> Regards
>>
>> --zoly
>>
>> ________________________________
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
12:30 p.m.
Totally agree. I often turned checked exceptions into unchecked ones for
core JDK classes. For example, MethodNotFoundException. That is totally
programmer's fault.
On Fri, Dec 12, 2008 at 12:53 PM, Greg Barton <greg_barton(a)yahoo.com> wrote:
I dunno, man. Do you catch every NullPointerException or
ArrayIndexOutOfBoundsException you could? I'm thinking not.
Yes, exceptions should be caught whenever possible, but forcing that on the
programmer too much can lead to this kind of pattern:
try {
...
} catch(OverusedAndThusAnnoyingCheckedException e) {}
This is CONCENTRATED EVIL. :) See "Item 65: Don't ignore exceptions" in
Josh Bloch's "Effective Java." Heck just see all of chapter 9. :)
In fact, this leads me to Bloch's "Item 58: Use checked exceptions for
recoverable conditions and runtime exceptions for programming errors." It
strikes me that a resource being missing can often be a programming error
(fat fingered resource name) but can also be a recoverable communication
error. (remote storage unavailable) I still lean towards an unchecked
exception, though, because more often than not the resources in question
will be loaded from jars in the classpath, and failure to load them will me
mostly due to programmer error.
--- On Fri, 12/12/08, James C. Owen <jco(a)kbsc.com> wrote:
> From: James C. Owen <jco(a)kbsc.com>
> Subject: Re: [rules-dev] Drools API improvement sugestion
> To: "Greg Barton" <greg_barton(a)yahoo.com>, "Rules Dev
List" <
rules-dev(a)lists.jboss.org>, zoly(a)daxtechnologies.com
> Date: Friday, December 12, 2008, 11:15 AM
> Greetings:
>
> Not too often do I get personally involved in Java/J2EE
> disputes among
> those who are virtually experts at this game. However,
> exceptions is
> one of my pet peeves. NOT catching an exception shows a
> bit of
> disregard for the integrity of the product itself and,
> IMHO,
> everything should be in a try / catch block such that the
> exception is
> NOT caught only in trivial circumstances. (And if it's
> so trivial
> that it doesn't need a try/catch block, is it necessary
> at all?)
>
> As an old C programmer (yes, there are still a few of us
> around) if we
> thought that we were really, really good programmers we
> would run
> "lint" on our program before sending it to QA.
> And QA always ran
> "lint" just for the fun of showing up our poor
> programming. It was
> usually an humbling experience. Catching all of the
> exceptions during
> testing should be required. Catching all of the exceptions
> during run
> time is debatable. I would think that NOT catching
> exceptions is what
> makes for run time problems that could have been caught
> during compile/
> design time.
>
> The final question is WHAT to do with a caught exception?
> This is
> where experience shows up and with some you can just toss
> an error
> statement in a log somewhere with a warning. Others
> require an error
> routine and stopping the program. Then that becomes a
> matter of
> judgement. Catch and release? Nahhh... I only fish to
> eat, not for
> sport. :-)
>
> Just two cents.
>
> SDG
> James Owen
> Senior Consultant / Architect
> 817.656.4553 office
> 214.684.5272 cell
> Founder KnowledgeBased Systems Corporation
> http://www.kbsc.com
> Founder October Rules Fest
> http://www.OctoberRulesFest.org
> Blogs:
> http://JavaRules.blogspot.com [Java-Oriented Rulebased
> Systems]
> http://ORF2009.blogspot.com [October Rules Fest]
> http://exscg.blogspot.com/ [Expert Systems Consulting
> Group]
> "This above all: to thine own self be true,
> And it must follow, as the night the day,
> Thou canst not then be false to any man."
> Hamlet, Act 1, Scene III
> http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
>
>
>
>
> On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
>
> > I vote for runtime exception. That gives you the
> option of catching
> > it or not. Just from experience I can't tell you
> how nice it was
> > when HibernateException went from a checked to an
> unchecked exception.
> >
> > That being said, the API methods that can throw it
> should still
> > declare it in the throws clause, even if it's a
> runtime exception.
> > That helps IDEs like Eclipse wrap method calls in the
> right try/
> > catch blocks when generating code. (See the
> "Source->Surround With-
> > >try/catch block" menu option)
> >
> > --- On Fri, 12/12/08, Zoltan Farkas
> <zoly(a)daxtechnologies.com> wrote:
> >
> >> From: Zoltan Farkas
> <zoly(a)daxtechnologies.com>
> >> Subject: RE: [rules-dev] Drools API improvement
> sugestion
> >> To: "Rules Dev List"
> <rules-dev(a)lists.jboss.org>
> >> Date: Friday, December 12, 2008, 10:10 AM
> >>> From my point of view as a developer who
> writes code
> >> against the api,
> >> I have to handle to case of a Resource not being
> there, or
> >> being
> >> invalid/corupt... theese are casses that I need to
> recover
> >> from in my
> >> code...
> >> and I have no way of knowing what do I need to
> catch and
> >> where, without
> >> first writing the code, run tests against it, and
> examine
> >> stack traces.
> >> I find this quite inefficient...
> >>
> >> If you google for ResourceNotFoundException, you
> will find
> >> out that
> >> there is quite a few APIs out there that implement
> it.
> >> There is other
> >> apis that have InvalidResourceException... or
> >> javx.resource.ResourceException
> >>
> >> My preference would be toward catched Exceptions
> in this
> >> case.
> >>
> >> --zoly
> >>
> >>
> >> ________________________________
> >>
> >> From: rules-dev-bounces(a)lists.jboss.org
> >> [mailto:rules-dev-bounces@lists.jboss.org] On
> Behalf Of
> >> Mark Proctor
> >> Sent: Thursday, December 11, 2008 8:04 PM
> >> To: Rules Dev List
> >> Subject: Re: [rules-dev] Drools API improvement
> sugestion
> >>
> >>
> >> Zoltan Farkas wrote:
> >>
> >> Based on current implementation, the following
> methods I
> >> think
> >> should throw a exception, something like:
> >> ResourceNotFoundException
> >>
> >> do you want this as runtime or catched exception?
> At the
> >> moment we are
> >> trying to avoid catched exceptions.
> >>
> >> Mark
> >>
> >>
> >>
> >>
> org.drools.compiler.PackageBuilder.addKnowledgeResource()
> >>
> org.drools.builder.impl.KnowledgeBuilderImpl.add()
> >>
> >> another option might be to verify the validity of
> a
> >> Resource
> >> object at creation time and make ResourceFactory
> factory
> >> methods throw
> >> ResourceNotFoundException.
> >>
> >> I believe the case of a "not found
> resource" the
> >> user of the api
> >> should be "ecouraged" to handle.
> >>
> >> Another case that might be needed to be handled
> could be
> >> InvalidResource?
> >>
> >> Let me know what you guys think
> >>
> >> Regards
> >>
> >> --zoly
> >>
> >> ________________________________
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev(a)lists.jboss.org
> >>
> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:08 p.m.
Greg Barton wrote:
I dunno, man. Do you catch every NullPointerException or
ArrayIndexOutOfBoundsException you could? I'm thinking not.
Yes, exceptions should be caught whenever possible, but forcing that on the programmer
too much can lead to this kind of pattern:
try {
...
} catch(OverusedAndThusAnnoyingCheckedException e) {}
This is CONCENTRATED EVIL. :) See "Item 65: Don't ignore exceptions" in
Josh Bloch's "Effective Java." Heck just see all of chapter 9. :)
In fact, this leads me to Bloch's "Item 58: Use checked exceptions for
recoverable conditions and runtime exceptions for programming errors." It strikes me
that a resource being missing can often be a programming error (fat fingered resource
name) but can also be a recoverable communication error. (remote storage unavailable) I
still lean towards an unchecked exception, though, because more often than not the
resources in question will be loaded from jars in the classpath, and failure to load them
will me mostly due to programmer error.
The general belief is that actually in practice few exceptions can be
truly recovered, if they can't be recovered then you might as well let
them bubble up to the root of the program for logging before it exits.
This is why many people catch the static exception wrap as runtime and
then re-throw - this is what we already do in the innards of drools all
over the place, turning possible static exceptions into runtime ones to
bubble up to the user.
Mark
--- On Fri, 12/12/08, James C. Owen <jco(a)kbsc.com> wrote:
> From: James C. Owen <jco(a)kbsc.com>
> Subject: Re: [rules-dev] Drools API improvement sugestion
> To: "Greg Barton" <greg_barton(a)yahoo.com>, "Rules Dev List"
<rules-dev(a)lists.jboss.org>, zoly(a)daxtechnologies.com
> Date: Friday, December 12, 2008, 11:15 AM
> Greetings:
>
> Not too often do I get personally involved in Java/J2EE
> disputes among
> those who are virtually experts at this game. However,
> exceptions is
> one of my pet peeves. NOT catching an exception shows a
> bit of
> disregard for the integrity of the product itself and,
> IMHO,
> everything should be in a try / catch block such that the
> exception is
> NOT caught only in trivial circumstances. (And if it's
> so trivial
> that it doesn't need a try/catch block, is it necessary
> at all?)
>
> As an old C programmer (yes, there are still a few of us
> around) if we
> thought that we were really, really good programmers we
> would run
> "lint" on our program before sending it to QA.
> And QA always ran
> "lint" just for the fun of showing up our poor
> programming. It was
> usually an humbling experience. Catching all of the
> exceptions during
> testing should be required. Catching all of the exceptions
> during run
> time is debatable. I would think that NOT catching
> exceptions is what
> makes for run time problems that could have been caught
> during compile/
> design time.
>
> The final question is WHAT to do with a caught exception?
> This is
> where experience shows up and with some you can just toss
> an error
> statement in a log somewhere with a warning. Others
> require an error
> routine and stopping the program. Then that becomes a
> matter of
> judgement. Catch and release? Nahhh... I only fish to
> eat, not for
> sport. :-)
>
> Just two cents.
>
> SDG
> James Owen
> Senior Consultant / Architect
> 817.656.4553 office
> 214.684.5272 cell
> Founder KnowledgeBased Systems Corporation
> http://www.kbsc.com
> Founder October Rules Fest
> http://www.OctoberRulesFest.org
> Blogs:
> http://JavaRules.blogspot.com [Java-Oriented Rulebased
> Systems]
> http://ORF2009.blogspot.com [October Rules Fest]
> http://exscg.blogspot.com/ [Expert Systems Consulting
> Group]
> "This above all: to thine own self be true,
> And it must follow, as the night the day,
> Thou canst not then be false to any man."
> Hamlet, Act 1, Scene III
> http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
>
>
>
>
> On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
>
>
>> I vote for runtime exception. That gives you the
>>
> option of catching
>
>> it or not. Just from experience I can't tell you
>>
> how nice it was
>
>> when HibernateException went from a checked to an
>>
> unchecked exception.
>
>> That being said, the API methods that can throw it
>>
> should still
>
>> declare it in the throws clause, even if it's a
>>
> runtime exception.
>
>> That helps IDEs like Eclipse wrap method calls in the
>>
> right try/
>
>> catch blocks when generating code. (See the
>>
> "Source->Surround With-
>
>>> try/catch block" menu option)
>>>
>> --- On Fri, 12/12/08, Zoltan Farkas
>>
> <zoly(a)daxtechnologies.com> wrote:
>
>>> From: Zoltan Farkas
>>>
> <zoly(a)daxtechnologies.com>
>
>>> Subject: RE: [rules-dev] Drools API improvement
>>>
> sugestion
>
>>> To: "Rules Dev List"
>>>
> <rules-dev(a)lists.jboss.org>
>
>>> Date: Friday, December 12, 2008, 10:10 AM
>>>
>>>> From my point of view as a developer who
>>>>
> writes code
>
>>> against the api,
>>> I have to handle to case of a Resource not being
>>>
> there, or
>
>>> being
>>> invalid/corupt... theese are casses that I need to
>>>
> recover
>
>>> from in my
>>> code...
>>> and I have no way of knowing what do I need to
>>>
> catch and
>
>>> where, without
>>> first writing the code, run tests against it, and
>>>
> examine
>
>>> stack traces.
>>> I find this quite inefficient...
>>>
>>> If you google for ResourceNotFoundException, you
>>>
> will find
>
>>> out that
>>> there is quite a few APIs out there that implement
>>>
> it.
>
>>> There is other
>>> apis that have InvalidResourceException... or
>>> javx.resource.ResourceException
>>>
>>> My preference would be toward catched Exceptions
>>>
> in this
>
>>> case.
>>>
>>> --zoly
>>>
>>>
>>> ________________________________
>>>
>>> From: rules-dev-bounces(a)lists.jboss.org
>>> [mailto:rules-dev-bounces@lists.jboss.org] On
>>>
> Behalf Of
>
>>> Mark Proctor
>>> Sent: Thursday, December 11, 2008 8:04 PM
>>> To: Rules Dev List
>>> Subject: Re: [rules-dev] Drools API improvement
>>>
> sugestion
>
>>> Zoltan Farkas wrote:
>>>
>>> Based on current implementation, the following
>>>
> methods I
>
>>> think
>>> should throw a exception, something like:
>>> ResourceNotFoundException
>>>
>>> do you want this as runtime or catched exception?
>>>
> At the
>
>>> moment we are
>>> trying to avoid catched exceptions.
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>>
> org.drools.compiler.PackageBuilder.addKnowledgeResource()
>
> org.drools.builder.impl.KnowledgeBuilderImpl.add()
>
>>>
>>> another option might be to verify the validity of
>>>
> a
>
>>> Resource
>>> object at creation time and make ResourceFactory
>>>
> factory
>
>>> methods throw
>>> ResourceNotFoundException.
>>>
>>> I believe the case of a "not found
>>>
> resource" the
>
>>> user of the api
>>> should be "ecouraged" to handle.
>>>
>>> Another case that might be needed to be handled
>>>
> could be
>
>>> InvalidResource?
>>>
>>> Let me know what you guys think
>>>
>>> Regards
>>>
>>> --zoly
>>>
>>> ________________________________
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>>
>>>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:21 p.m.
:-) the good old checked Exception debate.
I am attempting to load a package published by guvnor, so rules change
at runtime. I will have to handle theese exceptions aniways ...
However I would like to be able to differentiate between a "resource not
avail/invalid" and other runtime exceptions if we choose to go the way
of unchecked exceptions...
Using checked of uncheck exceptions it all depends what the common use
case for the API will be...
--zoly
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Greg Barton
Sent: Friday, December 12, 2008 12:53 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools API improvement sugestion
I dunno, man. Do you catch every NullPointerException or
ArrayIndexOutOfBoundsException you could? I'm thinking not.
Yes, exceptions should be caught whenever possible, but forcing that on
the programmer too much can lead to this kind of pattern:
try {
...
} catch(OverusedAndThusAnnoyingCheckedException e) {}
This is CONCENTRATED EVIL. :) See "Item 65: Don't ignore exceptions" in
Josh Bloch's "Effective Java." Heck just see all of chapter 9. :)
In fact, this leads me to Bloch's "Item 58: Use checked exceptions for
recoverable conditions and runtime exceptions for programming errors."
It strikes me that a resource being missing can often be a programming
error (fat fingered resource name) but can also be a recoverable
communication error. (remote storage unavailable) I still lean towards
an unchecked exception, though, because more often than not the
resources in question will be loaded from jars in the classpath, and
failure to load them will me mostly due to programmer error.
--- On Fri, 12/12/08, James C. Owen <jco(a)kbsc.com> wrote:
From: James C. Owen <jco(a)kbsc.com>
Subject: Re: [rules-dev] Drools API improvement sugestion
To: "Greg Barton" <greg_barton(a)yahoo.com>, "Rules Dev List"
<rules-dev(a)lists.jboss.org>, zoly(a)daxtechnologies.com
Date: Friday, December 12, 2008, 11:15 AM
Greetings:
Not too often do I get personally involved in Java/J2EE disputes among
those who are virtually experts at this game. However, exceptions is
one of my pet peeves. NOT catching an exception shows a bit of
disregard for the integrity of the product itself and, IMHO,
everything should be in a try / catch block such that the exception is
NOT caught only in trivial circumstances. (And if it's so
trivial
that it doesn't need a try/catch block, is it necessary at all?)
As an old C programmer (yes, there are still a few of us
around) if we
thought that we were really, really good programmers we would run
"lint" on our program before sending it to QA.
And QA always ran
"lint" just for the fun of showing up our poor programming. It was
usually an humbling experience. Catching all of the exceptions during
testing should be required. Catching all of the exceptions during
run
time is debatable. I would think that NOT catching exceptions is
what
makes for run time problems that could have been caught during
compile/ design time.
The final question is WHAT to do with a caught exception?
This is
where experience shows up and with some you can just toss an error
statement in a log somewhere with a warning. Others require an error
routine and stopping the program. Then that becomes a matter of
judgement. Catch and release? Nahhh... I only fish to eat, not for
sport. :-)
Just two cents.
SDG
James Owen
Senior Consultant / Architect
817.656.4553 office
214.684.5272 cell
Founder KnowledgeBased Systems Corporation http://www.kbsc.com Founder
October Rules Fest http://www.OctoberRulesFest.org
Blogs:
http://JavaRules.blogspot.com [Java-Oriented Rulebased Systems]
http://ORF2009.blogspot.com [October Rules Fest]
http://exscg.blogspot.com/ [Expert Systems Consulting Group] "This
above all: to thine own self be true, And it must follow, as the night
the day, Thou canst not then be false to any man."
Hamlet, Act 1, Scene III
http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
> I vote for runtime exception. That gives you the
option of catching
> it or not. Just from experience I can't tell you
how nice it was
> when HibernateException went from a checked to an
unchecked exception.
>
> That being said, the API methods that can throw it
should still
> declare it in the throws clause, even if it's a
runtime exception.
> That helps IDEs like Eclipse wrap method calls in the
right try/
> catch blocks when generating code. (See the
"Source->Surround With-
> >try/catch block" menu option)
>
> --- On Fri, 12/12/08, Zoltan Farkas
<zoly(a)daxtechnologies.com> wrote:
>
>> From: Zoltan Farkas
<zoly(a)daxtechnologies.com>
>> Subject: RE: [rules-dev] Drools API improvement
sugestion
>> To: "Rules Dev List"
<rules-dev(a)lists.jboss.org>
>> Date: Friday, December 12, 2008, 10:10 AM
>>> From my point of view as a developer who
writes code
>> against the api,
>> I have to handle to case of a Resource not being
there, or
>> being
>> invalid/corupt... theese are casses that I need to
recover
>> from in my
>> code...
>> and I have no way of knowing what do I need to
catch and
>> where, without
>> first writing the code, run tests against it, and
examine
>> stack traces.
>> I find this quite inefficient...
>>
>> If you google for ResourceNotFoundException, you
will find
>> out that
>> there is quite a few APIs out there that implement
it.
>> There is other
>> apis that have InvalidResourceException... or
>> javx.resource.ResourceException
>>
>> My preference would be toward catched Exceptions
in this
>> case.
>>
>> --zoly
>>
>>
>> ________________________________
>>
>> From: rules-dev-bounces(a)lists.jboss.org
>> [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of
>> Mark Proctor
>> Sent: Thursday, December 11, 2008 8:04 PM
>> To: Rules Dev List
>> Subject: Re: [rules-dev] Drools API improvement
sugestion
>>
>>
>> Zoltan Farkas wrote:
>>
>> Based on current implementation, the following
methods I
>> think
>> should throw a exception, something like:
>> ResourceNotFoundException
>>
>> do you want this as runtime or catched exception?
At the
>> moment we are
>> trying to avoid catched exceptions.
>>
>> Mark
>>
>>
>>
>>
org.drools.compiler.PackageBuilder.addKnowledgeResource()
>>
org.drools.builder.impl.KnowledgeBuilderImpl.add()
>>
>> another option might be to verify the validity of
a
>> Resource
>> object at creation time and make ResourceFactory
factory
>> methods throw
>> ResourceNotFoundException.
>>
>> I believe the case of a "not found
resource" the
>> user of the api
>> should be "ecouraged" to handle.
>>
>> Another case that might be needed to be handled
could be
>> InvalidResource?
>>
>> Let me know what you guys think
>>
>> Regards
>>
>> --zoly
>>
>> ________________________________
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:49 p.m.
Greg Barton wrote:
I vote for runtime exception. That gives you the option of catching
it or not. Just from experience I can't tell you how nice it was when
HibernateException went from a checked to an unchecked exception.
Yes there has been a general backlash against forced static exceptions,
especially say if you know the Resource is from a byte[] or String.
That being said, the API methods that can throw it should still
declare it in the throws clause, even if it's a runtime exception.
I was just
planning to let people do null checks, but I can do this
instead - what do people prefer?
That helps IDEs like Eclipse wrap method calls in the right
try/catch blocks when generating code. (See the "Source->Surround
With->try/catch block" menu option)
--- On Fri, 12/12/08, Zoltan Farkas <zoly(a)daxtechnologies.com> wrote:
> From: Zoltan Farkas <zoly(a)daxtechnologies.com>
> Subject: RE: [rules-dev] Drools API improvement sugestion
> To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
> Date: Friday, December 12, 2008, 10:10 AM
> >From my point of view as a developer who writes code
> against the api,
> I have to handle to case of a Resource not being there, or
> being
> invalid/corupt... theese are casses that I need to recover
> from in my
> code...
> and I have no way of knowing what do I need to catch and
> where, without
> first writing the code, run tests against it, and examine
> stack traces.
> I find this quite inefficient...
>
> If you google for ResourceNotFoundException, you will find
> out that
> there is quite a few APIs out there that implement it.
> There is other
> apis that have InvalidResourceException... or
> javx.resource.ResourceException
>
> My preference would be toward catched Exceptions in this
> case.
>
> --zoly
>
>
> ________________________________
>
> From: rules-dev-bounces(a)lists.jboss.org
> [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of
> Mark Proctor
> Sent: Thursday, December 11, 2008 8:04 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Drools API improvement sugestion
>
>
> Zoltan Farkas wrote:
>
> Based on current implementation, the following methods I
> think
> should throw a exception, something like:
> ResourceNotFoundException
>
> do you want this as runtime or catched exception? At the
> moment we are
> trying to avoid catched exceptions.
>
> Mark
>
>
>
> org.drools.compiler.PackageBuilder.addKnowledgeResource()
> org.drools.builder.impl.KnowledgeBuilderImpl.add()
>
> another option might be to verify the validity of a
> Resource
> object at creation time and make ResourceFactory factory
> methods throw
> ResourceNotFoundException.
>
> I believe the case of a "not found resource" the
> user of the api
> should be "ecouraged" to handle.
>
> Another case that might be needed to be handled could be
> InvalidResource?
>
> Let me know what you guys think
>
> Regards
>
> --zoly
>
> ________________________________
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5853
days inactive
5854
days old
9 comments
5 participants
participants (5)
-
David Sinclair -
Greg Barton -
James C. Owen -
Mark Proctor -
Zoltan Farkas