You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2006/11/02 18:33:16 UTC
Quick proposal: remove exceptions from Roller.getXXXManager() methods
I've started notice a little nit pick that I have about the fact that we
throw a RollerException from all of the Roller.getXXXManager() methods.
I find myself constantly feeling that this is a totally useless
exception which often causes the code to be overly littered with
try/catch blocks which ultimately have no real use.
Would anyone object to changing these methods to not throw an exception?
Does anyone see any value in having these methods throw that exception?
Also, just to be clear, this work wouldn't be done until after the 3.1
release is finalized.
-- Allen
Re: Quick proposal: remove exceptions from Roller.getXXXManager()
methods
Posted by Craig L Russell <Cr...@Sun.COM>.
> Just going to resend this one since I didn't hear back from anyone. I
> plan to make this change while I am cleaning up the business layer
> a bit.
>
> Basically, we don't need to throw a RollerException from every call to
> Roller.getXXXManager() because 1) it's incredibly unlikely that will
> cause a problem and if it does then we can throw a RuntimeException
> instead and 2) none of the current implementation throws the exception
> anyways. So right now it's just forcing lots of try/catch blocks
> which
> are of no value.
Yes, do it.
Craig
Craig Russell
clr@apache.org http://db.apache.org/jdo
Re: Quick proposal: remove exceptions from Roller.getXXXManager() methods
Posted by Matt Raible <mr...@gmail.com>.
On 11/16/06, Allen Gilliland <al...@sun.com> wrote:
> Just going to resend this one since I didn't hear back from anyone. I
> plan to make this change while I am cleaning up the business layer a bit.
>
> Basically, we don't need to throw a RollerException from every call to
> Roller.getXXXManager() because 1) it's incredibly unlikely that will
> cause a problem and if it does then we can throw a RuntimeException
> instead and 2) none of the current implementation throws the exception
> anyways. So right now it's just forcing lots of try/catch blocks which
> are of no value.
Sounds good, and very Spring-like. ;-)
Matt
>
> -- Allen
>
>
> Allen Gilliland wrote:
> > I've started notice a little nit pick that I have about the fact that we
> > throw a RollerException from all of the Roller.getXXXManager() methods.
> > I find myself constantly feeling that this is a totally useless
> > exception which often causes the code to be overly littered with
> > try/catch blocks which ultimately have no real use.
> >
> > Would anyone object to changing these methods to not throw an exception?
> > Does anyone see any value in having these methods throw that exception?
> >
> > Also, just to be clear, this work wouldn't be done until after the 3.1
> > release is finalized.
> >
> > -- Allen
>
--
http://raibledesigns.com
Re: Quick proposal: remove exceptions from Roller.getXXXManager()
methods
Posted by Allen Gilliland <al...@sun.com>.
Just going to resend this one since I didn't hear back from anyone. I
plan to make this change while I am cleaning up the business layer a bit.
Basically, we don't need to throw a RollerException from every call to
Roller.getXXXManager() because 1) it's incredibly unlikely that will
cause a problem and if it does then we can throw a RuntimeException
instead and 2) none of the current implementation throws the exception
anyways. So right now it's just forcing lots of try/catch blocks which
are of no value.
-- Allen
Allen Gilliland wrote:
> I've started notice a little nit pick that I have about the fact that we
> throw a RollerException from all of the Roller.getXXXManager() methods.
> I find myself constantly feeling that this is a totally useless
> exception which often causes the code to be overly littered with
> try/catch blocks which ultimately have no real use.
>
> Would anyone object to changing these methods to not throw an exception?
> Does anyone see any value in having these methods throw that exception?
>
> Also, just to be clear, this work wouldn't be done until after the 3.1
> release is finalized.
>
> -- Allen