This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On Tue, 2004-07-06 at 12:22, David Daney wrote: > > If don't like the idiom new InternalError().initCause(), then add a > constructor to InternalError (and perhaps Error also) so that you can > pass the cause as a constructor parameter. As pointed out, Classpath does not add to the published, public, API of the core classes intentionally for compatibility. I too think RuntimeException would be incorrect in these situations, clearly an error should be thrown instead that indicates the dire situation the runtime is now in and the need to fix a potential library bug. The use of initCause() would seem appropriate if a cause exists. While applications can recover from many forms (maybe all) RuntimeExceptions, it is probably impossible to recover from InternalErrors. Thanks, Brian -- Brian Jones <cbj@gnu.org>
Attachment:
signature.asc
Description: This is a digitally signed message part
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |