throw with String

Osvaldo Doederlein opinali at
Wed Sep 15 15:46:11 PDT 2010

As my $2c, translated excerpt of my latest article (Brazilian Java
Magazine's cover story on the Java 7 language - too bad the new
delay...): "One endless debate about the Java language is checked
exceptions. Some Pharisees consider this a design error. (...) It's
true though that checked exceptions can result in bulky code,
especially with badly-designed APIs: checked exceptions that should
have been unchecked; failure to define a good hierarchy (...) Adding
everything - ARM, Multi-Catch, Final Rethrow and API tunings like
ReflectiveOperationException, and also other specs like EJB 3 (no
RemoteException) - exception handling has become MUCH cleaner in Java
7. We keep the huge advantage of Java of allowing tight policies for
error handling, ensuring compiler validation, but without imposing a
high price in boilerplate, repetitive code."

For another $2c, the only design mistake (IMHO) and remaining problem,
is that exceptions should have been defined as a special kind of
interface (just like annotations in Java 5), so we could use multiple
inheritance for really good exception hierarchies, and also to prevent
abuse (it's extremely rare the need of any custom code inside
exception classes, other that trivial stuff like
constructors/getters/setters for properties, which could be
compiler-generated just like javac does for for annotations). Removing
the explicit "new" operator from throw's syntax would also provide the
runtime with some extra leeway for optimization (reusing exception
objects automatically when possible; allocating a lightweight stub
implementation [basically just doing a longjmp] when the exception's
properties and stack trace are never used, etc.) Too bad that
Microsoft, with C#, ignored the great opportunity to fix and enhance
Java's checked exceptions, preferring the easier and "demagogic"
option to just drop them. The horrendous absence of checked exceptions
is the single thing that makes C# hard for me to love, even with its
many cool features.

And yep, -1 to that idea of throwing strings or other simple values. :)


2010/9/15 Rémi Forax <forax at>:
> Le 15/09/2010 21:50, Ralf Ebert a écrit :
>>> Beside the organizational details, throwing RuntimeException all over
>>> the place is not very useful. You would have to support better pattern
>>> matching to make it bearable. Setting up an exception type hierarchy
>>> will pay off. Maybe scripting is the only exception but this is
>>> something Java is not the best choice for.
>> For errors that are supposed to be handled in code, exception
>> hierarchies and 'throw new MyException()' statements are perfectly fine
>> of course. But a fair share of exceptions thrown in Java software are
>> exceptions that can never be specifically handled. This includes
>> assertions and situations that can only occur because of programming
>> errors. For these, exception hierarchies are often declared without
>> need, because 'throw new RuntimeException' in considered somewhat in bad
>> style by some programmers (without much reason in my humble opinion).
> Do you mean that it's not useful to make a difference between
> a NPE and an AIOOB ?
>> Sorry for not noticing the 'project coin ended' message, I'll file a bug
>> report about the proposal.
>> - Ralf
> Rémi

More information about the coin-dev mailing list