Does it hurt to have self explanatory exception names for exceptions ?
It also helps when a tool sees a stacktrace to provide "hyperlinking" to
the relevant docs or
even the class mentioned in there - there could even be automatic
quickfixes made based on
these (i.e. "Create method foo on class X" when NonexistentMethodException)
I know the reason you want them out of the spec is to avoid having to
define when each exception is thrown,
but just stating that "non recoverablity" is definitly not the only
usecase for specific exception classes/messages.
/max
The spec currently defines the following subclasses of
DefinitionException: NonexistentTypeException,
NonexistentMemberException, NonexistentFieldException,
NonexistentMethodException, NonexistentConstructorException.
Honestly I don't think there is much value to standardizing these
exceptions. It's not like they're ever recoverable or anything.
I would like to remove them from the spec and just say
"DefinitionException" instead.
Any objections?