Just a quick reply as I have to go in to work today and will probably be
swamped the second I get in.
I think the original idea for the switch was something like this.
1. We need to get rid of methods throwing the general Exception. Let's
switch to TorqueException in most cases.
2. I think this came from Fedor, but i could easily be wrong. Someone
said that this is going to make it impossible for the objects to
implement certain interfaces and generally make things more difficult to
work with than if we went with a RuntimeException subclass.
3. It was noted that the throwing of Exception already caused this
problem and switching to TorqueException was still an improvement. We
could decide whether TorqueException was a declared or runtime exception
later.
The need to change to a runtime exception was immediately apparent when
fulcrum's security classes could no longer compile due to the change.
Since I needed them working, I reverted one change of Exception to
TorqueException back to Exception. I only meant to do this until a
better way could be decided upon.
The use of a runtime exception by torque is not without supporters.
Some say that contrary to sun's advise, it is best to go with a runtime
exception except in cases where inheritance and interfaces are not going
be a problem. These are clearly a problem in a very normal usage of
torque.
So do we switch TorqueException to a runtime exception and drop
TorqueRuntimeException which I don't think is being used much? Or
switch from TorqueException to TorqueRuntimeException?
john mcnally
On Tue, 2002-08-27 at 20:33, Stephen Haberman wrote:
> John McNally and I have been having an enlightening (for me anyway)
> conversation on IRC about the proposed change of save() throwing
> TorqueException to Exception.
>
> >From my standpoint, the benefit was having a consistent checked
> exception used across all of Torque and being able to differentiate
> these from regular Exceptions/RuntimeExceptions.
>
> However, using TorqueException means that the OM object can't implement
> an interface that defines save() as throwing a different Exception (say
> the TurbineSecurityException as in Fulcrum). Where as before, with the
> general Exception, they could.
>
> The proposed solution John picked up on and said had been mentioned
> before was to use a TorqueRuntimeException.
>
> John made this excellent analogy:
>
> Good checked exceptions are AccessViolationException. An application can
> specifically catch this and do smart logic...e.g. prompt the user for a
> login/password.
>
> Bad checked exceptions are TorqueException. What the devil can an
> application intelligently do with a TorqueException? Retry the database
> query? Basically, it can only tell the user "sorry, an error happened".
>
> There exists the idea that instead of bad checked exceptions,
> RuntimeExceptions should be used instead. This way, an application can
> check all general runtime exceptions and say "Sorry, something weird
> happened".
>
> So also means you can do:
>
> om.getRelatedOm().setName("name");
>
> And it won't through any checked exceptions. It could through a
> TorqueRuntimeException, but general practice says you'll always have to
> worry about RuntimeExceptions anyway and any checked exceptions that
> would result from this operation you couldn't really respond any better
> to than a RuntimeException.
>
> Also, using TorqueRuntimeException would allow callers to differentiate
> it so you could, say, catch and rewrap as a generalized
> DataLayerException or what not.
>
> I really like this approach and assuming John agrees after he returns in
> a bit, will start implementing it.
>
> Does it sound good? Anyone see any issues with it?
>
> - Stephen
>
> > -----Original Message-----
> > From: James A. Hillyerd [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 27, 2002 6:19 PM
> > To: Turbine Torque Developers List
> > Subject: Re: why doesn't .save() throw TorqueException
> >
> > If you look at the CVS log, it got changed to Torque exception, and
> then
> > changed back because:
> >
> > "throwing TorqueException breaks fulcrum so i undo the change"
> -mpoeschl
> >
> > It seems like it's fulcrum that's broken to me. =)
> >
> > I don't make use of the save method for this reason, although there
> are
> > a number of places I'd like to use it, instead of checking whether to
> do
> > an insert or update.
> >
> > -james
> >
> > On Tue, 2002-08-27 at 13:43, Stephen Haberman wrote:
> > > I was just writing some exception wrapping code and after coming
> upon it
> > > time and time again, why does the om save method throw Exception
> instead
> > > of translating any Exceptions to TorqueException?
> > >
> > > Can I change this to conform with how the rest of Torque throws
> > > TorqueExceptions?
> > >
> > > Thanks,
> > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:turbine-torque-dev-
> > [EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:turbine-torque-dev-
> > [EMAIL PROTECTED]>
> > >
> > >
> > --
> > [] James A. Hillyerd <[EMAIL PROTECTED]> - Java Software Engineer
> > [] PGP 1024D/D31BC40D F87B 7906 C0DA 32E8 B8F6 DE23 FBF6 4712 D31B
> C40D
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:turbine-torque-dev-
> > [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:turbine-torque-dev-
> > [EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
