[vote] Standardizing OM for throwing TorqueException

[Mathieu Frenette <ma...@freeborders.com>]

I'm about to start porting the OM for throwing TorqueException instead of
Exception. This change should be 100% backward compatible, because all
existing client code which is catching Exception will also catch
TorqueException.

My initial goal was to modify only the OM classes (by modifying the
velocimacros), since it's the part that is the most exposed to users.

However, after much consideration and browsing through the code, I realized
that if we go up to the source and also modify the BasePeer and Torque
classes, we will get much cleaner code all the way down through the OM.

Since BasePeer and Torque are presently throwing Exception, we would have to
wrap those exceptions into TorqueException from within the OM classes.

However, if BasePeer and Torque were modified to throw TorqueException
instead, we could just let those exceptions flow through the OM classes,
which would make the code cleaner, and avoid excessive exception wrapping.

I know those two classes are really the corner stone of the framework.  But,
theoritically, this should also be 100% backward compatible. So it's really
yours to decide whether they should be modified in this action item.

[vote]
Should BasePeer and Torque classes be modified for throwing TorqueException,
in addition to OM classes?

Best Regards,

	Mathieu Frenette
	Software Architect
	Freeborders Canada


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [vote] Standardizing OM for throwing TorqueException

[Eric Dobbs <er...@dobbse.net>]

On Wednesday, February 20, 2002, at 04:02  PM, Daniel Rall wrote:

> Mathieu, you have my +1 to modify the Torque Java source and Velocity
> templates to throw TorqueException instead of Exception.  This is a
> fully backwards compatible change, and we can debate at length whether
> TorqueException should be a checked or unchecked exception _after_ the
> change is made.

Couldn't agree more.  You have my +1 as well.
-Eric

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [vote] Standardizing OM for throwing TorqueException

[Daniel Rall <dl...@finemaltcoding.com>]

mathieu.frenette@freeborders.com (Mathieu Frenette) writes:

> I'm about to start porting the OM for throwing TorqueException instead of
> Exception. This change should be 100% backward compatible, because all
> existing client code which is catching Exception will also catch
> TorqueException.
>
> My initial goal was to modify only the OM classes (by modifying the
> velocimacros), since it's the part that is the most exposed to users.
>
> However, after much consideration and browsing through the code, I realized
> that if we go up to the source and also modify the BasePeer and Torque
> classes, we will get much cleaner code all the way down through the OM.
>
> Since BasePeer and Torque are presently throwing Exception, we would have to
> wrap those exceptions into TorqueException from within the OM classes.
>
> However, if BasePeer and Torque were modified to throw TorqueException
> instead, we could just let those exceptions flow through the OM classes,
> which would make the code cleaner, and avoid excessive exception wrapping.
>
> I know those two classes are really the corner stone of the framework.  But,
> theoritically, this should also be 100% backward compatible. So it's really
> yours to decide whether they should be modified in this action item.
>
> [vote]
> Should BasePeer and Torque classes be modified for throwing TorqueException,
> in addition to OM classes?

Mathieu, you have my +1 to modify the Torque Java source and Velocity
templates to throw TorqueException instead of Exception.  This is a
fully backwards compatible change, and we can debate at length whether
TorqueException should be a checked or unchecked exception _after_ the
change is made.

                             Thanks, Dan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>