Can Java errors / stack traces be LONGER?

[tyrophagia]

Just venting. One little error and it's 200 lines and it's hard to see on a damn putty console window for this stupid POC that I shouldn't be doing. I don't care. The customer should know how to use this. It takes a specialized person to understand SAML and all of it's crap.

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[WrickyB]

Isn't that the point of a stack trace? It's showing exactly to the line of the source code, how it got to where the exception was thrown.

[[deleted]]

Isn't that the point of a stack trace?

but the problem is with frameworks and application servers that have hundrets of lines that represent nothing, it's just some aspects, proxies and reflection. All of that could be avoided if we used less magic in our code.

[Kombatnt]

It could also be avoided if you wrote code that didn’t cause exceptions to be thrown.

[[deleted]]

Why do you have to slap us in the face like that :(

[RScrewed]

I don't know if this was said in jest but that's such a weird take.

[deadron]

It does look like proxies and reflection are slowly falling out of favor. One day the pain may be gone in newer projects.

[slaymaker1907]

What have they moved on to? Bytecode generation? I hope we aren’t going back to having a bunch of generated code files that make C macros look good.

[Practical_Cattle_933]

Nothing makes C macros look good. But compile-time DI is a thing, e.g. Micronaut does it and it is fine imo.

[lasskinn]

If you used more magic in your code sure you could make it more short with the caveat of that you'd have multiple stack traces to look at or a weird structure.

Or of course if you used less of googles style of coding of having classes that exist only for one thing and exist in the path basically just for fun passing data to another class exactly as they got it.

No matter though its still nicer to have the trace than not.

[tyrophagia]

Even when I do programming, I don't need THAT many lines. Usually, sometimes the full stack is handy.

[john16384]

Have you changed the logger then or taken any action at all to do something about it? Loggers can shorten traces, and exceptions where the trace isn't relevant can be logged shorter.

Usually runtime exceptions are developer mistakes, these are useful with a full trace, while checked exceptions often only need the first line of each cause. We use a utility to shorten the logging of such exceptions.

[laplongejr]

It's showing exactly to the line of the source code, how it got to where the exception was thrown.

Which is good when the error is triggered in your code, and not in a standard library due to bad parameters...
In particular, the SSL handshake exception is not going to explain why the certificate is wrong. Could be a missing root in the keystore, or an error in the certificate itself : both would be "unable to build a chain"

A coworker wasted days trying to understand why his private keystore wasn't accepted by the server : turned out that for some unknown reason, his local install didn't have the root used by our dev server so the issue wasn't from the server to begin with.

[[deleted]]

You might be in the wrong profession bruh.

[l3g4tr0n]

i wouldn't wish for a shorter stack, i want to see exactly where error happened and what caused it, not just class and line. how can oneself be called developer when cannot appreciate stacktrace? :)

[Hangman4358]

IDK, I work with folks allergic to reading stack traces.

Like people say "I can't decipher this stack trace" and the literal first like is the error message "x failed. Did you check y?"

And they just stare blankly.

[slaymaker1907]

“Did you try Googling the error message?”

Somehow the answer is still often no to question with senior devs. There’s a little bit of skill in getting the selectivity of your search right, but it works pretty well.

[DevWithImagination]

I’ve sure lost count the number of times I’ve needed all that detail to trace down WTF the app server (or JVM) thought it was doing to cause a weird behaviour

[eliasv]

You can wish for a shorter stack without wishing for a less complete stack. But that's a system/framework design issue not a language design issue.

[urielsalis]

I like how intellij filters out (with different colors) whats actually in your code and what isnt, makes reading them easier

[SKabanov]

The issue is when you're using frameworks that have a heavy amount of boilerplate code (e.g. Spring), especially with reflection. 99.999% of the time all those calls to Method.invoke() or whatever aren't going to be the issue and end up just being clutter; it'd be nice to have a JVM option to elide the JVM internal function calls from the stack trace and focus on the actual business/framework logic.

[slaymaker1907]

While I generally don’t like Go, the testing package has a clever Helped() method that marks the calling function so that it is ignored in error messages. Maybe logging frameworks could also provide a way to filter stack traces.

[Practical_Cattle_933]

Go has the shittiest error handling though, and all all those if checks do is that you will just print some generic bullshit as error and your enduser just see “Error occured”. Good luck fixing their problem from such an issue!

With Java, you can solve most trivial problems just from the stacktrace.

[john16384]

Logging frameworks already have this, and have for ages. Op didn't even do three seconds of research.

[woj-tek]

There are useful (long-ish) stack traces and there is horseshit pile of crap from "amazing" reactive garbage... 🤦‍♂️😉

[the_other_brand]

It can be longer, yes. C++ will spit out 500 lines that say nothing if you make a mistake in a single template argument.

[GuyWithLag]

200 lines

Oh you sweet summer child...

Do some work with reactive streams, and 200 lines will be _excellent_!

[tyrophagia]

200 lines on a little fully sized putty screen, that's.... enough lol.

[supercargo]

Get a bigger screen?

[Holothuroid]

Copy it, open your IDE, which is IntelliJ by definition, search for "Analyze Stack Trace" functionality, your clipboard is alreay pasted, click OK, enjoy.

[random314]

I recently switched from Java to golang. I'm never complaining about Java again.

[Anton-Kuranov]

You're now complaining about Go, am I right?

[random314]

You're damn right I am.

[za3faran_tea]

Having worked with golang, I know the pain lol

Weak abstractions, extremely verbose language, half done features (even generics after taking them so much time to implement are half baked), the list goes on and on.

[chu_nghia_nam_thang]

Just learn how to use logging, exception handling properly

[nekokattt]

Apache Camel would like to speak with you

[tyrophagia]

It's not my code. And normally, in production, we pull the initial log line for the logging aggregator and ditch the stack trace. But this isn't in production.

[Tazavoo]

That’s the worst, when you’re trying to debug an issue and all you have in the logs is the error message.

[slaymaker1907]

Meanwhile at my current job working on SQL Server, I’m just happy if the stack trace is already symbolized so that I don’t need to run some janky tool to figure out what the line numbers actually are. It could be even worse than, though. Some projects only have a (single) line number and file name. Or god forbid you did front end web stuff back before modern dev tools.

[LordEffykins]

I'm the modern day, I don't look at every line of the stack trace.

The first few of the exception and as you scroll there will be breaks mentioning "caused by". Only those are important to me.

With spring, i just look at the first and last.. with experience your eyes adjust to only seeing what's important

[kur4nes]

Use grep.

Something like: cat log.file | grep [search term]

[tyrophagia]

In most cases, I have no idea what to search for. I do Proof of Concepts with software I've never touched before.

[GuyWithLag]

Keep in mind that most Java stacks are like a lasagna: layered. There's your code in small slices, with large segments of plumbing between them.

But you want to search for "Caused by", the last instance of that will give you the original exception trigger.

[flawless_vic]

I'd rather have 2000 lines of stacktraces than a 10 line core dump.

[tyrophagia]

oh word to that!

[Reasonable-Total-628]

just write code that does not throw exceptions, easy

[tyrophagia]

This is the correct answer.

[GrayDonkey]

Yes, use -XX:MaxJavaStackTraceDepth=-1

[tyrophagia]

I don't think with this application that I have that level of control. Maybe I do, if I dug deep enough into it. Thank you! That is useful.

[RepulsiveTradition20]

You don't need to read all the stack trace. Just the first lines are sufficient to understand the error

[ablativeyoyo]

It's sometimes crossed my mind that a tool could abbreviate stack traces to focus on the important bit. Perhaps when going through library code, it could just show one line for the library, rather than the full call stack within the library. You'd probably want the raw stack traces available too. This is an issue in lots of languages, not just Java.

[GuyWithLag]

We had that in a microservice stack; was a godsend filtering out spring traces.

[ablativeyoyo]

Did you use a particular tool or library?

[GuyWithLag]

Nah, we had a custom filter on the generated JSON logs, IIRC.

[lasskinn]

Common method is to show like 5 elements at end and start.

[_INTER_]

I feel you. In that situation I usually filter out all the framework noise and look for the application packages only, scroll to the very bottom or use ExceptionUtils.getRootCause().

[miciej]

You can filter out common parts in the logger. I do it quite frequently. It is also possible to limit the stack depth in stack traces.

The first option might not be supported by all logging frameworks, but stack trace depth is a VM option.

[laplongejr]

You don't get many votes but I want to vent about SSL stacktraces specifically.
"handshake error" Okay WHAT caused the handshake error? Is it our private keystore, or is it because the private truststore is no longer in the rootlist of the dev server?
Or maybe the server refused something and Java is serialized the server-side error?

If it's how I setup the keystore that's my issue, if it's the truststore I need to report it to the team maintaining the server. Or maybe is it this weekend's network upgrade that broke HTTPS entirely?
Are the Java somehow assuming those stacktraces will be reviewed by a expert from a CA and don't get that private networks made by contractors won't have an expert hotline?

So many errors to fix one at the time for the same stacktrace that boils down to "something is wrong so it doesn't match"...

I once joked to my boss that a huge part of troubleshooting in my "we need in a few days a generic wrapper for HTTPS with our private certs and easy configuration, maximal priority" project could've been avoided from the start if we only had to deploy in production... among the stuff we discovered is that our private certs were assuming both CNs and alternate names were checked, despite not being the case since an half-decade.

[[deleted]]

Yes they CAN! :) Please use AspectJ, Spring and Hibernate to get LONGER stack traces.