Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Java Bullshifier

takipi.github.io

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Show HN: Java Bullshifier

#41

Post by hinkley »

vbezhenar wrote: post #25
antoineMoPa wrote: post #4

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.

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,…

The problem has historically been that most J2EE frameworks overly rely on delegation, because of GoF.

I don't like seeing the same 5 stack frames in the same class appear three separate times in a single stack trace. Because what does that stack trace say?

It says it took Foo five function calls -on itself- to figure out it's not responsible for an operation. So Foo asks Bar to do it, and after half a dozen more function calls someone asks Foo all over again. Who takes 5 function calls to figure out it's STILL not responsible for this action. Lather, Rinse, Repeat.

And how do you set a breakpoint in that call tree? Which time do you want to debug it? How many more times was it called before the exception was thrown?

Re: Show HN: Java Bullshifier

#42

Post by codingdave »

desireco42 wrote: post #9

It was about time somebody creates something like this. I do have a complain, classes are named random. If you used a tool that generates human like names, it would still be random but looked much better. I will see to create a similar rails tool. I intend to test just stress of people who will look at the code and try to understand what it does.

> I will see to create a similar rails tool. I intend to test just stress of people who will look at the code and try to understand what it does.

I think rails does that out of the box.

Re: Show HN: Java Bullshifier

#44

Post by frugalmail »

antoineMoPa wrote: post #4

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.

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?

Re: Show HN: Java Bullshifier

#45

Post by frugalmail »

CSDude wrote: post #13
brimstedt wrote: post #10

Earlier quoted context omitted.

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?

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-Naksh...

That's a problem on the other side of the keyboard.

Re: Show HN: Java Bullshifier

#46

Post by twic »

tkfx wrote: post #8

Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…

How were you able to go back in time to create Spring?

Re: Show HN: Java Bullshifier

#47

Post by tkfx »

orf wrote: post #33
tkfx wrote: post #15

Earlier quoted context omitted.

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.

You mean like Sentry? That's been around for ages.

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/) and you can see some more samples after you sign up.

Re: Show HN: Java Bullshifier

#48

Post by aikah »

antoineMoPa wrote: post #4

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.

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.

Re: Show HN: Java Bullshifier

#49

Post by tkfx »

CocaKoala wrote: post #14
tkfx wrote: post #8

Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…

I don't know why, but the fact that this is an actual tool that's been designed to solve a real problem that you guys faced (as opposed to being a random project that somebody dreamed up to make fun of Java or to see if they could do it) makes me really happy.

Java is alive and kicking. It's the most popular programming language in the world. As such, it also attracts most of the fire. We hope to see more colorful projects like these go open source. Thanks for the comment! :)

Re: Show HN: Java Bullshifier

#50

Post by mark242 »

twic wrote: post #46
tkfx wrote: post #8

Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…

How were you able to go back in time to create Spring?

You misspelled "Hibernate". Hope this helps.
Post reply on HN