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]>
