On 10/31/06, Scott Balmos <sbalmos@xxxxxxxxxxxxxxxxxxx> wrote:
Jim Weirich wrote:
> On 10/31/06, *Edward Sumerfield* <esumerfd@xxxxxxxxxxxxxx
> <mailto:esumerfd@xxxxxxxxxxxxxx>> wrote:
>
> I agree with your disagreement, I wonder if my perception more tightly
> correlates in the Java community and is less relevant elsewhere.
> Perhaps we could increased the correlation by limiting our set to
> those Java programmers that have not experienced other languages.
>
> If we limit our sample to Java programmers, I would not be surprised
> by the correlation. But we haven't actually established the
> correlation yet.
>
> I too am surprised that we have seen any strong support for checked
> exceptions in this group.
This really is more of a technicality, since it still boils down to the
implementing language, but I would technically say that SOAP supports
checked exceptions, since you can define each operation's SOAP fault
types explicitly in the WSDL file.
The SOAP API as implemented in Java throws checked exceptions. This is
not a feature of SOAP but a design decision made by the Sun programmer
that speced the API. The Ruby SOAP client to the same SOAP service
will not suffer from the same problem, dispite the common declaration
of the faults.
Sun made the same decision with RMI, JDBC etc. I am hoping that the
mistakes of the past help us improve our future. Hibernate fixed the
SQLException problem.
Personally, I have not yet done enough different projects to really make
this authoritative... But the pattern I use in the big multi-module JEE
/ SOAP app that I'm writing in my free time is to make exceptions that
require large interruption of the client's / user's workflow checked,
while everything else unchecked.
Why does "large interruption" to the use case give checked exceptions
an advantage? What alternate outcome do you envisioning with a checked
exception?
For example, I have checked UnauthorizedException,
UserAlreadyExistsException, etc since these would require logging in as
a different user, asking for another username to create, etc. Invalid
object IDs and generally bad data for a single method call are
unchecked, since the current form action can be redisplayed with an
appropriate error scream at the user, and the user's train of thought
and workflow (hopefully) won't be completely derailed.
So, I am reading that if I see UnauthorizedException then the
programmer is expected to implement an alternative flow. This makes
sence as a design goal but how does the "checked" part improve the
liklyhood that all the correct flows will be implemented?
The design goal is to ensure that all UnauthorizedExceptions result in
correct alternate flow. So, if a flow is incorrect then a
developer/tester needs to know that it is wrong as soon as possible.
Given the propensity of developers to add empty or
System.out.println's in their catch blocks, what it the probablility
that the system delivered to production will have all these catch
blocks filled with the correct functionality?
My argument is that, at the time of adding the auth call, the
programmer probably doesn't know the appropriate alternate flow and
yet they are forced to put in the catch, this fact increases the
likleyhood that catch blocks will exist with "// TODO I will do this
later" in them if you are lucky and using eclipse, and "// I will do
this later" in them if you are not.
Hope that explanation made sense... If not, charge the wasted time to my
expense account. I'll reimburse you in the future when I actually have
an expense account. :)
That will be -$0.02 please, for considering my response.
--Scott
--
Ed
|