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
> 

Reply via email to