As chance would have it, I recently wrote myself a note for "audit
constructor choices in JDK exceptions" as a possible little project for
JDK 8. I have also been annoyed by some missing exception constructors
and I filled in one such omission in JDK 7, "6935997 Please add a nested
throwable constructor to AssertionError."
So if we were to systematically to through and look to add all four
constructors to all exception types in the JDK, then I agree
GenericSignatureFormatError should have them too, but in the absence of
that effort, I think just adding the constructor taking a string message
is sufficient for now.
-Joe
On 6/16/2011 9:49 AM, Mike Duigou wrote:
I guess that's what I should have suggested--that all exceptions/errors with
public constructors should support all four of the standard constructors
declared by 1.4+ Throwable. It's been occasionally annoying to use an exception
class that's missing one or more of the standard constructors. It has usually
been an exception class outside the JDK but it seems like a reasonable practice
to include all four.
Mike
On Jun 16 2011, at 09:35 , Joe Darcy wrote:
On 6/16/2011 9:21 AM, Mike Duigou wrote:
Perhaps the chained exception constructor would also be useful. I can imagine
that whatever was parsing the signature might throw an exception with it's
parse state that could then be captured (without needing to use initCause()) in
the thrown GenericSignatureFormatError
Mike
Hi Mike.
At least as currently used in the JDK, the String constructor would suffice --
there are no causal exceptions in how the signature parser is coded.
(If we were to add a third constructor taking a cause, we should also add a
fourth constructor taking a cause and a message.)
-Joe
