Joerg Heinicke wrote:
On 16.04.2004 16:47, Ugo Cei wrote:
The conventional wisdom is that it's better to have the compiler
remind you that you have to catch most exceptions, because that's part
of the contract. My opinion, instead, is that checked exceptions are a
very bad way of enforcing contracts between callers and callees.
This is where I don't follow you.
It's a question of where to handle the exceptions. Many projects have a
way of handling arbitrary exceptions that slip through the cracks.
Checked exceptions encourage handling the exception as close to the
cause as possible. Unchecked exceptions encourage global exception
handling.
In many situations, allowing exceptions to be propagated to the sitemap
would actually be preferred. Most examples in the cocoon codebase seem
to support that notion. There are times where it does make sense to
handle close to the cause of the exception, but that is usually only
when you have an alternative way to get the information.
What I hate in Java are untyped collections, that force me to cast when
retrieving an object out of them, and long vs. Long (was it called
auto-boxing?). Both will be fixed in Java 1.5 IIRC.
Be careful with this. In my initial testing with Java 1.5, it is still
quite easy to circumvent typed collections. I highly recommend using
the "-Xlint:all" command line argument for the javac compiler. It will
warn you if you cast a typed collection to an untyped collection.
It does clean up a lot of cruft in your code that makes it really nice.
Not to mention the new java.lang.StringBuilder will also provide more
optimization. The only difference between StringBuilder and
StringBuffer is that the StringBuilder is unsynchronized--it is finally
offered because most usages of StringBuffer are all within the same
thread. Lower thread contention means faster runtime.
