Reinier Zwitserloot wrote:
> BGGA's checked exception handling is extremely complex. I don't like
> it at all.
>
You can gripe about that, but it is the only thing that really makes a
code block work "normally".
If you have something like:
for ( ... )
{
// some code that throw IOException
}
then you'd expect to have to catch IOException or declare "throws
IOException".
If you don't have exception transparency, then when you use closures to
do something like
forEachWombat( ... )
{
// do some stuff that throws IOException
}
You'd get totally different behavior -- which is *not* acceptable in my
book.
Exception transparency is complex in terms of implementation -- but
rather simple in terms of usage. It's really a missing piece of Java
generics and exception handling in Java as I see.
As for Collections.sort() -- if you want this to allow throwing of
checked exceptions from the Comparable then this is a dramatic change in
the contract and, yes, Collections.sort() would have to be
reimplemented. There's still a big different between "public T foo()"
and "public T foo() throws E" -- the former is saying only serious
unforeseen runtime exceptions could possibly occur in foo() -- that's
the contract. That the Comparable contract and changing that is a big
change. On the other hand, that's not to say that Callable wouldn't be
a lot better as "public T call() throws E" than "public T call() throws
Exception".
--
Jess Holle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
