JDK-6798955 : Make MirroredTypesException be the parent class of MirroredTypeException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.lang.model
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2009-01-29
  • Updated: 2010-06-07
  • Resolved: 2010-06-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
To allow fewer catch blocks to do more, it would help if MirroredTypesException and MirroredTypeException to have superclass-subclass relationship rather than just both being runtime exceptions.  MirroredTypeException should be the specialized type since it fundamentally just should return a list of length one.

Comments
EVALUATION Subclassing of MirroredType[s]Exception changed as part of fix for 6519115.
07-06-2010

PUBLIC COMMENTS Seems harmless but also pointless. Typical processor code would be catching either one or the other exception type at a time: SomeAnno ann = element.getAnnotation(SomeAnno.class); try { ann.someMethodReturningClass(); } catch (MirroredTypeException x) { TypeMirror theReturnValue = x.getTypeMirror(); // ... } try { ann.someMethodReturningClassArray(); } catch (MirroredTypesException x) { List<? extends TypeMirror> theReturnValue = x.getTypeMirrors(); // ... } For it to be useful for a catch block of MirroredTypesException to also get MirroredTypeException with a singleton list, the calling code would have to have no idea whether the method it was calling returned Class or Class[]. But that would only happen if the calling code were operating reflectively on an annotation type not known to it statically - in which case Element.getAnnotation(Class) is useless, since you would more easily work with Element.getAnnotationMirrors(). As the Javadoc for getAnnotation says, "this method is intended for callers that are written to operate on a known, fixed set of annotation types", exactly the callers that will be catching either MirroredTypeException or MirroredTypesException when calling known, fixed methods.
29-01-2009

EVALUATION API usability issue should be addressed.
29-01-2009