Show HN: Stackifier for Scala – Make sense of your Scala stack trace(stackifier.com)
stackifier.com
Show HN: Stackifier for Scala – Make sense of your Scala stack trace
http://www.stackifier.com/scala.html
9 comments
It'd be nice if it could handle nested exceptions. I pasted in an ActorInitializationException caused by a PersistenceException and it only parsed the first half of the stack trace, all of which was Scala/Akka library code. The nested exception was ignored and that's where the calls to my code are.
Thanks for the idea! We'll look into adding support for 'caused by'.
In the meantime you can simply remove the lines pertaining to the enclosing exception.
Based on the "Paste your call stack (Java/Scala)", I want to assume/hope that this works with vanilla Java code as well.
Our team would throw their wallets at you if you made this an IDE plugin for IDEA and Eclipse (we use both).
Our team would throw their wallets at you if you made this an IDE plugin for IDEA and Eclipse (we use both).
Yes, this works for vanilla Java as well. A version which is more suitable for Java can be found at http://www.stackifier.com (w/o scala.html). An IDE plugin is indeed something we may consider.
Unfortunately, I don't think that this is very useful. I am a novice Scala programmer, but I have quite a lot of C++ experience. I remember when I first tried to decode template errors - a single typo can cause multiple pages of hardly readable error messages. After a few weeks/months, you start to see what's behind the matrix and it becomes much easier to interpret those seemingly messed up errors. I believe the same is true for Scala.
I get it, but then I don't - if you know what I mean - I looked at the Java version yesterday.
So typically I would just do a Ctrl + F against the log and search for my package name e.g. co.uk.planetjones. And voila it finds the first call that originated in my code.
With stackifier I would have to copy my Exception message to the clipboard, load the website, paste my Exception in and then view the output with the Red Marker on the right hand side.
I'm not saying it's not a neat little tool - I just don't know if it necessarily saves me time i.e. it's probably quicker for me to search for my package in the log file or console log. And the advantage of using the console log is the IDE will hyperlink the line number so I just click on it to go to the line of my code where the Exception originated. With stackifier I need to remember the line number, open the file and go to that line.
So typically I would just do a Ctrl + F against the log and search for my package name e.g. co.uk.planetjones. And voila it finds the first call that originated in my code.
With stackifier I would have to copy my Exception message to the clipboard, load the website, paste my Exception in and then view the output with the Red Marker on the right hand side.
I'm not saying it's not a neat little tool - I just don't know if it necessarily saves me time i.e. it's probably quicker for me to search for my package in the log file or console log. And the advantage of using the console log is the IDE will hyperlink the line number so I just click on it to go to the line of my code where the Exception originated. With stackifier I need to remember the line number, open the file and go to that line.
Long time ago, when I was a BEA Senior Tech Support, Java stack traces (thread dumps) were often the only way to troubleshoot the situation. So, I built a tool that took multiple versions of thread dumps (IBM vs Sun vs. JRocket vs different version) and converted them to normalized XML.
Then, I visualized those individual threads within a thread dump with cross-references on the locks held. Made it 100 times easier to figure out dead- and live-locks.
I also did a pretty-printed side-by side reports of the same thread across multiple thread-dumps.
It was interesting enough that it was used within my group, I did a presentation on JavaONE about it and published in (now dead) Weblogic Developer's journal.
Never managed to open-source it (the code was really ugly). Wish I did. People I sent it to during my tech support days kept using it in very large companies even after I left BEA.
Then, I visualized those individual threads within a thread dump with cross-references on the locks held. Made it 100 times easier to figure out dead- and live-locks.
I also did a pretty-printed side-by side reports of the same thread across multiple thread-dumps.
It was interesting enough that it was used within my group, I did a presentation on JavaONE about it and published in (now dead) Weblogic Developer's journal.
Never managed to open-source it (the code was really ugly). Wish I did. People I sent it to during my tech support days kept using it in very large companies even after I left BEA.
This is great. I find it's sometimes difficult to navigate through some stack traces. so good idea.
However, I don't see myself copying and pasting stack traces. Would love to have something built in in my workflow. :)
However, I don't see myself copying and pasting stack traces. Would love to have something built in in my workflow. :)
Nice, would be great as an IDEA or Eclipse plugin
anything equivalent for Clojure?
The dollars in the title just look tacky.
As a Scala developer I've never felt the need for this product, but I'm prepared to believe others do.
As a Scala developer I've never felt the need for this product, but I'm prepared to believe others do.
They might look tacky in first place, but I assume they are related to the dollar signs in the stacktraces of code with threading and anonymous functions. :)
...
at com.company.IdentityVerifier$$anonfun$go$2$$anonfun$apply$2.apply$mcII$sp(IdentityVerifier.scala:19)
...
at com.company.UserCreatorMain$1.run(UserCreatorMain.java:37)
...Agreed.
I look at Scala stacktraces fairly often (but not that often, because static typing) and I didn't get the dollar signs until I read the blurb on their page. Notice that Scala doesn't replace S with $ as they're done, but rather puts $s around words. I think it would be better to use a headline like
Make Sense of your $Scala$$stack.trace
I look at Scala stacktraces fairly often (but not that often, because static typing) and I didn't get the dollar signs until I read the blurb on their page. Notice that Scala doesn't replace S with $ as they're done, but rather puts $s around words. I think it would be better to use a headline like
Make Sense of your $Scala$$stack.trace