3:22 a.m.
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?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
3:29 a.m.
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?
3:34 a.m.
On Wed, Jan 14, 2009 at 8:29 PM, Max Rydahl Andersen
<max.andersen(a)redhat.com> wrote:
Does it hurt to have self explanatory exception names for exceptions
?
No, but that is up to the implementation. It can throw a subclass of
DefinitionException, that is permitted by the spec.
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)
Again, this still works if the subclass is vendor-specific.
I know the reason you want them out of the spec is to avoid having to
define
when each exception is thrown,
No, the real reason is that there is a corner case when processing the
XML format where we're not sure if its a method or a field that is
missing ;-)
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
3:37 a.m.
> I know the reason you want them out of the spec is to avoid
having to define
> when each exception is thrown,
>
No, the real reason is that there is a corner case when processing the
XML format where we're not sure if its a method or a field that is
missing ;-)
okey - then I just hope the reference implementation will get good
exception handling for the rest ;)
/max
6:24 a.m.
On 14 Jan 2009, at 09:37, Max Rydahl Andersen wrote:
>> I know the reason you want them out of the spec is to avoid having
>> to define
>> when each exception is thrown,
>>
> No, the real reason is that there is a corner case when processing
> the
> XML format where we're not sure if its a method or a field that is
> missing ;-)
>
okey - then I just hope the reference implementation will get good
exception handling for the rest ;)
Yup, still on the list to do. The plan is to go through at the CR
stage and standardize the format of all exception messages (just for
you Max) as by then we will know all the kinds of info that needs to
go into them.
5793
days inactive
5793
days old
4 comments
3 participants
participants (3)
-
Gavin King -
Max Rydahl Andersen -
Pete Muir