6 ms·

I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you

I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you are seeking between 200 lines of call stack prints.

brimstedt 10y ago
When something blows, arent you just happy to get as much information as possible? I remember when developing in VB classic, youd get something lile "error -68377388484". Perhaps you prefer this?
- antoineMoPa 10y ago
  I prefer something in between. Something like: the method that called the current method, the line number and a sentence describing the exception. No need to know the function-that-called-the-function-that-called-the-fun[...]
  - Sharlin 10y ago
    In my experience the direct caller usually tells me very little about the root cause of the exception. The interesting context is often at least ten frames separate from the proximate cause in even moderately complex Java programs. Of course, often there's an additional couple dozen lines in the trace that aren't very useful...
  - deleted 10y ago
    [deleted]
  - frugalmail 10y ago
    That's sounds like you work on very small projects. That function-that-called-the-function-that-called-the-fun could behave very differently through that path due to calling parameters, environment or data issues.
- CSDude 10y ago
  The level of verbosity is good, however when you replace almost all your catch exceptions with ex.printStacktraces() it gets enormously large and unmaintainable across a large project when too many things prints stack taces concurrently. Not the way I like to do it, however too many people do that unfortunetaly: http://plg.uwaterloo.ca/~migod/846/current/projects/09-NakshatriHegdeThandra-report.pdf http://plg.uwaterloo.ca/~migod/846/current/projects/09-Naksh...
  - deleted 10y ago
    [deleted]
  - frugalmail 10y ago
    That's a problem on the other side of the keyboard.
tkfx 10y ago
It's not only that. OverOps also shows the variable state and source code of every stack frame. It's like using a debugger in production.
- orf 10y ago
  You mean like Sentry? That's been around for ages.
  - tkfx 10y ago
    Sentry doesn't give you the local variable state at the moment of error. Only environment related data. We use it as well, but only for JS frontend. It's more of an error tracker, rather than a root cause analysis tool. The benefit is that it's wider and doesn't only focus on Java, but you'll still need to spend time going through logs to actually troubleshoot those errors and understand what was wrong with the state that caused them. With OverOps, you go deep on Java, with every variable value, overlaid on the code across the call stack. Without looking at / relying on logs. There's a short video here (http://www.overops.com/ http://www.overops.com/) and you can see some more samples after you sign up.
    - MaulingMonkey 10y ago
      > Sentry doesn't give you the local variable state at the moment of error. I noticed the sentry json API at least supports them, so this may be a limitation of the specific language SDK as currently stands: https://docs.sentry.io/clientdev/interfaces/stacktrace/ https://docs.sentry.io/clientdev/interfaces/stacktrace/ (see "vars") (I'm fiddling around with writing a Windows C++ SDK for sentry with a C ABI...)
    - LewisJEllis 10y ago
      Hey, Lewis from Sentry here. "Sentry doesn't give you local variable state" is not entirely accurate - it varies from platform to platform. We don't do it for Java (you're obviously ahead of us there), but we do with at least Python and PHP off the top of my head. I wish we could do it for JavaScript too, but it's only partially feasible and only in a very questionable way. Note that in your browser JS use case, we capture breadcrumbs to show you console logs, user interaction events, XHRs, navigation events, prior errors, etc leading up to the error, so you should be able to easily just reproduce the error state rather than digging through logs to find out what it was. If you still find yourself needing to dig through logs to troubleshoot JS errors reported via Sentry, I'd really like to hear more about your experience to see if we can make it better.
vbezhenar 10y ago
As an experienced Java developer I love long Java stacktraces and I miss them in most languages. In 90% cases stacktrace allows to find a bug without any debugging, because it's just very obvious where it is. Of course if someone doesn't care about exceptions, it's just a bad style. Exception in the production log is like red light and alarm sound, BUG-BUG-BUG. I saw projects, which throw stacktrace after stacktrace, gigabytes of stacktraces (and then archived those teralogs and noone ever watched them). But those projects have much more problems, verbose logs is the least of them. Yes, with heavy framework usage, especially when those frameworks generate proxy classes and wrappers and god knows what, it's often 2-3 lines of useful information between 90 lines of not-so-useful library or even autogenerated code. But only developer can judge it, environment should preserve anything.
- mdaniel 10y ago
  and then archived those teralogs and noone ever watched them I champion Sentry wherever I go, as it has an outstanding "fold these common explosions into one event" behavior, in addition to managing the _lifecycle_ of an exception/error, from first encounter through resolved in release, to the dreaded reoccurence. I do keep a terminal open for my curiosity but I'm much happier with computers watching logs than me having to
  - smw 10y ago
    Sentry is outstanding for this! There's an open source self hosted version available too.
    - mdaniel 10y ago
      That's the one I exclusively use because I'm a control freak :-)
- tkfx 10y ago
  I think the tool that we're building (http://www.overops.com http://www.overops.com) could be something that might help with the log data overload. It basically gives you everything you need to troubleshoot an error - without relying on log files, while deduping recurrences of the same event. It gets all the required information (source, stack and variable state), through a native JVM agent that transmits everything directly to the tool.
hota_mazi 10y ago
You can accuse Java stack traces of a bunch of things but they do the exact opposite of hiding the information you are seeking.
frugalmail 10y ago
Two questions: How do you debug your non-trivial applications: sprinkling print statements, some real time debugger, channeling your chosen god? Why do you think that's better?
- antoineMoPa 10y ago
  Well placed print statements. I print only a few things. Of course, in Java & eclipse, it is hard to see the result because so much stuff gets printed (The stack trace, Maven showing useless details, tomcat doing the same, etc.). In C/C++/rust/JavaScript/Python, the last things you see on a failed build/run is usually the detail that will help you fix the problem. The information is organized to be read by someone.
  - whitenoice 10y ago
    You can easily control logging level with slf4j etc, you can run maven in quiet mode if you want to see only errors. I don't think these are java lang issues, its more of a people problem that they don't quite understand the language and the tools they use in depth.
  - frugalmail 10y ago
    I've done my fair share of work in those languages and it almost never has anything to do with the last line. Typically following back into some stupid === vs. == error or some dynamic typing issue many frames up the call stack. Even C++ is a nightmare to traceback when you use boost/STL heavily
aikah 10y ago
Java stack traces are verbose because Java devs write verbose code. Java stack traces are nice and readable. Just look at a Go stack trace, it'll make you want to vomit.
bborud 10y ago
Java's exceptions are not overly verbose. Blame bad developers and worse architects for insane stack depths.
Terr_ 10y ago
> overly verbose exception outputs I would love to have that problem. I work with old PHP where frequently it just barfs a fatal error with no stack-trace at all.
paulddraper 10y ago
Java's stacktraces aren't they much more verbose then Ruby, Python, or JS. In fact, IMO they aren't verbose enough: they have only the file name of the source file, not the full path.
- deleted 10y ago
  [deleted]

brimstedt 10y ago

When something blows, arent you just happy to get as much information as possible? I remember when developing in VB classic, youd get something lile "error -68377388484". Perhaps you prefer this?

antoineMoPa 10y ago
I prefer something in between. Something like: the method that called the current method, the line number and a sentence describing the exception. No need to know the function-that-called-the-function-that-called-the-fun[...]
- Sharlin 10y ago
  In my experience the direct caller usually tells me very little about the root cause of the exception. The interesting context is often at least ten frames separate from the proximate cause in even moderately complex Java programs. Of course, often there's an additional couple dozen lines in the trace that aren't very useful...
- deleted 10y ago
  [deleted]
- frugalmail 10y ago
  That's sounds like you work on very small projects. That function-that-called-the-function-that-called-the-fun could behave very differently through that path due to calling parameters, environment or data issues.
CSDude 10y ago
The level of verbosity is good, however when you replace almost all your catch exceptions with ex.printStacktraces() it gets enormously large and unmaintainable across a large project when too many things prints stack taces concurrently. Not the way I like to do it, however too many people do that unfortunetaly: http://plg.uwaterloo.ca/~migod/846/current/projects/09-NakshatriHegdeThandra-report.pdf http://plg.uwaterloo.ca/~migod/846/current/projects/09-Naksh...
- deleted 10y ago
  [deleted]
- frugalmail 10y ago
  That's a problem on the other side of the keyboard.

tkfx 10y ago

It's not only that. OverOps also shows the variable state and source code of every stack frame. It's like using a debugger in production.

orf 10y ago
You mean like Sentry? That's been around for ages.
- tkfx 10y ago
  Sentry doesn't give you the local variable state at the moment of error. Only environment related data. We use it as well, but only for JS frontend. It's more of an error tracker, rather than a root cause analysis tool. The benefit is that it's wider and doesn't only focus on Java, but you'll still need to spend time going through logs to actually troubleshoot those errors and understand what was wrong with the state that caused them. With OverOps, you go deep on Java, with every variable value, overlaid on the code across the call stack. Without looking at / relying on logs. There's a short video here (http://www.overops.com/ http://www.overops.com/) and you can see some more samples after you sign up.
  - MaulingMonkey 10y ago
    > Sentry doesn't give you the local variable state at the moment of error. I noticed the sentry json API at least supports them, so this may be a limitation of the specific language SDK as currently stands: https://docs.sentry.io/clientdev/interfaces/stacktrace/ https://docs.sentry.io/clientdev/interfaces/stacktrace/ (see "vars") (I'm fiddling around with writing a Windows C++ SDK for sentry with a C ABI...)
  - LewisJEllis 10y ago
    Hey, Lewis from Sentry here. "Sentry doesn't give you local variable state" is not entirely accurate - it varies from platform to platform. We don't do it for Java (you're obviously ahead of us there), but we do with at least Python and PHP off the top of my head. I wish we could do it for JavaScript too, but it's only partially feasible and only in a very questionable way. Note that in your browser JS use case, we capture breadcrumbs to show you console logs, user interaction events, XHRs, navigation events, prior errors, etc leading up to the error, so you should be able to easily just reproduce the error state rather than digging through logs to find out what it was. If you still find yourself needing to dig through logs to troubleshoot JS errors reported via Sentry, I'd really like to hear more about your experience to see if we can make it better.

vbezhenar 10y ago

As an experienced Java developer I love long Java stacktraces and I miss them in most languages. In 90% cases stacktrace allows to find a bug without any debugging, because it's just very obvious where it is. Of course if someone doesn't care about exceptions, it's just a bad style. Exception in the production log is like red light and alarm sound, BUG-BUG-BUG. I saw projects, which throw stacktrace after stacktrace, gigabytes of stacktraces (and then archived those teralogs and noone ever watched them). But those projects have much more problems, verbose logs is the least of them. Yes, with heavy framework usage, especially when those frameworks generate proxy classes and wrappers and god knows what, it's often 2-3 lines of useful information between 90 lines of not-so-useful library or even autogenerated code. But only developer can judge it, environment should preserve anything.

mdaniel 10y ago
and then archived those teralogs and noone ever watched them I champion Sentry wherever I go, as it has an outstanding "fold these common explosions into one event" behavior, in addition to managing the _lifecycle_ of an exception/error, from first encounter through resolved in release, to the dreaded reoccurence. I do keep a terminal open for my curiosity but I'm much happier with computers watching logs than me having to
- smw 10y ago
  Sentry is outstanding for this! There's an open source self hosted version available too.
  - mdaniel 10y ago
    That's the one I exclusively use because I'm a control freak :-)
tkfx 10y ago
I think the tool that we're building (http://www.overops.com http://www.overops.com) could be something that might help with the log data overload. It basically gives you everything you need to troubleshoot an error - without relying on log files, while deduping recurrences of the same event. It gets all the required information (source, stack and variable state), through a native JVM agent that transmits everything directly to the tool.

hota_mazi 10y ago

You can accuse Java stack traces of a bunch of things but they do the exact opposite of hiding the information you are seeking.

frugalmail 10y ago

Two questions: How do you debug your non-trivial applications: sprinkling print statements, some real time debugger, channeling your chosen god? Why do you think that's better?

antoineMoPa 10y ago
Well placed print statements. I print only a few things. Of course, in Java & eclipse, it is hard to see the result because so much stuff gets printed (The stack trace, Maven showing useless details, tomcat doing the same, etc.). In C/C++/rust/JavaScript/Python, the last things you see on a failed build/run is usually the detail that will help you fix the problem. The information is organized to be read by someone.
- whitenoice 10y ago
  You can easily control logging level with slf4j etc, you can run maven in quiet mode if you want to see only errors. I don't think these are java lang issues, its more of a people problem that they don't quite understand the language and the tools they use in depth.
- frugalmail 10y ago
  I've done my fair share of work in those languages and it almost never has anything to do with the last line. Typically following back into some stupid === vs. == error or some dynamic typing issue many frames up the call stack. Even C++ is a nightmare to traceback when you use boost/STL heavily

aikah 10y ago

Java stack traces are verbose because Java devs write verbose code. Java stack traces are nice and readable. Just look at a Go stack trace, it'll make you want to vomit.

bborud 10y ago

Java's exceptions are not overly verbose. Blame bad developers and worse architects for insane stack depths.

Terr_ 10y ago

> overly verbose exception outputs I would love to have that problem. I work with old PHP where frequently it just barfs a fatal error with no stack-trace at all.

paulddraper 10y ago

Java's stacktraces aren't they much more verbose then Ruby, Python, or JS. In fact, IMO they aren't verbose enough: they have only the file name of the source file, not the full path.

deleted 10y ago
[deleted]