Rough Draft Proposal: "Caused by" information provided when NPE is thrown

Jim Bethancourt jimbethancourt at
Thu Mar 26 07:46:24 PDT 2009

Hi everyone,

I realize I'm (very) new to the list, and I'm not sure this proposal fits
entirely in the scope of the Coin project since it's not exactly a language
level change, but I thought it best to err on the side of sharing my idea
and propose it before the deadline and seeing it shot down instead of
keeping it to myself. :-)

This is definitely a draft proposal and I would welcome any help if it is
offered, as this is only in the idea phase for me.  I'm by no means a
language designer, but I've seen NPEs countless numbers of times in
production stacktraces and often found it arduous and time consuming to
reproduce the NPE and thought it would be helpful to practitioners if such a
feature was added.

Thanks so much,


*AUTHOR(S):* Jim Bethancourt (Houston JUG leader --, you???


FEATURE SUMMARY: Provide more information about Null Pointer Exceptions on
the stacktrace when thrown through in the "Caused by" clause.  This feature
could be written using reflection APIs.  Should be suitable as a summary in
a language tutorial? NO

MAJOR ADVANTAGE: More information about what object reference is null would
be provided in the stacktrace "Caused by" clause

MAJOR BENEFIT: The programs running using it are easier to support and may
allow a quicker resolution of issues, and could also allow for easier
programmatic recovery from NPEs


ALTERNATIVES: could use a flag that enables the feature only during
development / troubleshooting




at com.code.NPEThrower(


would instead read


 at com.code.NPEThrower(


Caused by: Null return value: Object.getName()





at com.code.NPEThrower(


Caused by: Null reference




     code throwing NPE

} catch (NullPointerException npe){




SPECIFICATION: Describe how the proposal affects the grammar, type system,
and meaning of expressions and statements in the Java Programming Language
as well as any other known impacts.

This change would not affect the grammar, type system, or expression meaning
of statements in the Java Programming Language.

COMPILATION: How would the feature be compiled to class files? Show how the
simple and advanced examples would be compiled. Compilation can be expressed
as at least one of a desugaring to existing source constructs and a
translation down to bytecode. If a new bytecode is used or the semantics of
an existing bytecode are changed, describe those changes, including how they
impact verification. Also discuss any new class file attributes that are
introduced. Note that there are many downstream tools that consume class
files and that they may to be updated to support the proposal!

TESTING: How can the feature be tested?  Write code that throws a
NullPointerException and see if the field / method that is throwing the Null
Pointer Exception shows up in the Stacktrace as described.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature? no

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be
updated?  I don't imagine so, though reflection could potentially be used to
capture the object throwing the NPE


MIGRATION: Since this would be a change to the format of the stacktrace and
a new api method, there would not be any migration required.



EXISTING PROGRAMS: How do source and class files of earlier platform
versions interact with the feature? Not known.  Can any new overloadings
occur? No Can any new overriding occur? No



URL FOR PROTOTYPE (optional): none

More information about the coin-dev mailing list