On Jul 6, 5:17 pm, dvdav...@pobox.com wrote:

No.

If you can code an automatic check for whether the values are screwy,
though, you can do the next best thing -- throw an Error, and the
traceback will lead right to the offending part of the code, and with
a decent IDE as soon as you get the exception and click in the stack
trace you can be staring at the variable names in the culprit code.
With a good debugging IDE like Eclipse it will even be possible to
have it suspend on the throw statement and then use the debugger
interface to inspect the variables that are fubar and other state
relating to the method that was executing, and up the call chain too,
as well as the contents of various collections and suchlike at the
time the problem was detected.

I have thought about a similar trick before. You don't need to wait
for an error to find your stack call just do: new
Throwable().getStackTrace();

to ask the classloader to give you the full path to the class file,
which you can load the bytes of and interrogate. What I have never
figured out though is how to get the instance of the class that
invoked your method.

When you say variables and their "values" -- the term "value" is
actually ambiguous. In the case of an Integer or BigDecimal it's
clear, in the case of a ActionEvent object, what would the "value" be?
Such an object is inherently 'valueless' . If your objects are popular
Java library objects, this won't be a problem. Simply calling the
"toString()" method will produce what that object declares it's value
is. You can try it on Map objects, List objects, anything in the
Collections package. They will produce the expected result. I have
routinely used this to output arrays as such:

System.out.println(Arrays.asList(myArray)); // not advised for
performance

Also, any of the boxed primitive types or anything descending from
Number will produce what you're looking for

If the object in question are your own, override the toString()
method. I have frequently used this trick in combination with my
debugger. I use IntelliJ and by default it invokes the toString()
method on any object in it's watch window.

You can also override the toString() method in an anonymous inner
class for sorta '1-off' behavior. Such as:

BigInteger myInteger = new BigInteger("123456") {
    public void toString() {
       return "whatever you want";
    }
};

As far as your literal v. variables question goes. The only 'literal'
that can be declared in Java, that is also an object (and thus subject
to any kind of trickery) is String -- "Christian". Literal 'int' such
as 'myMethod(10)'
can not be interrogated at all because it's a primitive type. However,
any string output will produce the correct value.

Bottom line: I have tried to do something similar and stopped when my
Devilish plan required me to somehow divine the meaning of the byte
code of a Java class file. The above method may help you as a stop gap
measure.

Christian Bongiorno
http://christian.bongiorno.org

Note how debuggers can often display variable names.  Look at a class
file and you will see quite a few of the names embedded.

See http://mindprod.com/jgloss/debugger.html
http://mindprod.com/jgloss/jpda.html
http://mindprod.com/jgloss/javaclassformat.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com