How to get row column numbers in Java stacktraces

Question

In some languages, you can get the row column number on the stack, but in Java we only have row numbers.

To give you an example, in another language we can:

Error at <anonymous>:2:2 at Object.InjectedScript._evaluateOn (<anonymous>:641:39) at Object.InjectedScript._evaluateAndWrap (<anonymous>:580:52) at Object.InjectedScript.evaluate (<anonymous>:495:21)" 

Although this may not be a good example, as I am causing an error from the browser console, you can see the column numbers that are really useful in resolving errors.

To give you an example in Java (yes, the names have been changed):

 Caused by: java.lang.IllegalArgumentException: path was null at org.jboss.resteasy.specimpl.ResteasyUriBuilder.path(ResteasyUriBuilder.java:362) at enterprise.money.service(AbstractSomething.java:88) 

This results in line 88 containing

URI uri = uriInfo.getBaseUriBuilder().path(objectA).path(objectB).build();

Using stacktrace I have, I cannot check which .path call raised an exception. So my question is: are there any solutions allowing me to get a link to a column?

(To protect ourselves from possible alternative answers, we need a solution to get the column numbers, other answers, for example, how to get through the debugger or refactoring each builder template, etc., will not answer the question)

Answer 1

It's impossible.

You can get around it by formatting your code this way:

 URI uri = uriInfo .getBaseUriBuilder() .path(objectA) .path(objectB) .build(); 

---

In Oracle Java 8 you can write

 public static void main(String... ignored) { List<String> s = new ArrayList<>(); s.add("hello"); Predicate<? super String> predicate1 = (t) -> t.length() > 0; Predicate<? super String> predicate2 = (t) -> t.length() < 8; Predicate<? super String> predicate3 = null; List<String> collect = s.stream() .filter(predicate1) // 16 .filter(predicate2) // 17 .filter(predicate3) // 18 .collect(Collectors.toList()); } 

and you will get

 Exception in thread "main" java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:203) at java.util.stream.ReferencePipeline.filter(ReferencePipeline.java:161) at Example.main(Example.java:18) 

For Oracle JDK, this only looks like Java 8, not Java 7.

Answer 2

Reverse engineering for Java would be pretty painful. Theoretically, you can analyze the original source and find out which expression might cause such an exception.

If you have this as a problem, it is very likely that your lines are too complex / dense. Most IDEs simplify refactoring expressions to extract portions of code. This will give you more permission on where the exception was sent.

---

Another solution to this particular problem is to have methods with @NotNull, and the IDE can determine which arguments can be null, but should never be.

 URI uri = uriInfo.getBaseUriBuilder().path(objectA) .path(/*highlighted*/objectB).build(); 

The IDE may warn you that you are passing a variable to a method that cannot accept null . If you do this, you will understand these errors much earlier, and this will simplify the correction. (IDE comes with some quick fixes)

Note: in general, an incorrectly passed null API argument should throw a NullPointerException IMHO exception, but often an IllegalArgumentException exception is somewhat inconsistent.

As I see it, the argument for IllegalArgumentException is this:

• IllegalArgumentException is what you can expect from an application. The NullPointerException capture really smells.
• The handling of invalid null expected to be the same as other invalid arguments such as length -1

IMHO, passing null method that does not accept a null , is a programming error, and not what happens with the wrong input.

Answer 3

You cannot get columns from a stack trace.

What you can do is use intermediate variables so that each method calls a different line:

 UriBuilder builder = uriInfo.getBaseUriBuilder(); builder = builder.path(objectA); builder = builder.path(objectB); URI uri = builder.build(); 

This is painful, but can temporarily help find the problem, then you can return it as is.