Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A question for seasoned developers.

Do you still get a sinking feeling when you see a stack dump?

Any feelings of agitation, alarm, cold feet, confusion, consternation, dismay, dread, fear, trepidation?


For me it usually means that I'm not 100% sure about my design or I have not done enough testing of my code.

share|improve this question

closed as primarily opinion-based by durron597, Snowman, MichaelT, GlenH7, Ixrec May 19 at 23:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers 11

In general I love stacktraces. Most of them I cause by raising my own exception :)

What I hate is, when my app ran into a state where it obviously stopped working, but I don't get a stacktrace.

I currently work on a game that is being tested as a closed beta with 2500 players. When it crashes, we get sent a stacktrace, a screenshot and a server protocol and we can usually fix the problem within hours.

Of course I generally try to provoke stacktraces in my tests. Now if you get plenty of crashes in a product that you deliver, then that's definitely a problem, because your tests should have triggered them already.

I think you can hardly deliver a reliable product without hallway testing (except if you're into software verification and have a lot of money to spend). And if stacktraces show up before or during that phase, well that's excellent. If they show up after that, you did your job wrong.

share|improve this answer
+1 for a comprehensive automated bug gathering process (stacktrace, screenshot and server data) –  Gary Rowe Nov 12 '10 at 14:59
I used to work as senior support engineer for BEA. Java stack traces were often the only information I would get from customer's production system failing. I relied on them so much that I built a tool to parse and visualize the stack traces. Deadlocks and even livelocks troubleshooting became so much easier with that. I talked about that at JavaOne some years ago. –  Alexandre Rafalovitch Nov 12 '10 at 16:38
@Alexandre, how can you visualize a deadlock with a single stacktrace? Or did you get a thread dump of the whole JVM? –  user1249 Nov 14 '10 at 18:14
Whole JVM. I would ask a customer to take 3-5 thread dumps 30 seconds apart. The load on VM is not that great and I get enough information to do both deadlocks and live locks. For deadlocks specifically, I wrote some software that would show circular dependencies. It was especially nice when it would show 3 or 4 threads pointing at each other in a circle. Very hard to spot that one by eye-balling the 15 pages of thread dumps. –  Alexandre Rafalovitch Dec 2 '10 at 2:25

Stack traces are a thing of beauty that can be likened to watching wisps of dandylions dancing on a cool breeze on a summers day. The delicate nuances of the complex interplay within your code are brought forth and you are given a glimpse into the elegant world in which they reside. How can this inspire panic, fear, alarm, trepidation, terror, angst, fright or even, dare I say it, concern?

Your bug has given you insight, your stack trace has given you a path.

share|improve this answer
I weep at the poetic beauty of your answer. –  Tim Post Nov 15 '10 at 4:57

Stack trace is always like falling down the stairs. A core dump is like having crapped all over the place in addition to falling.

share|improve this answer
Yep - stack traces are much nicer than core dumps! –  Conor Nov 12 '10 at 13:18
+1: lol, computer poop. :D –  Stephen Furlani Nov 12 '10 at 13:26

Stack traces and core dumps are awesome, at least you're being given some information! Don't forget there are some languages (like prolog in the old days) that simply say "No".

Many people (and I include myself in them) find it non-trivial to debug a core dump, so I can understand the trepidation when you get one of those.

Stack traces (at least in the Java world) can indicate that your exception handling isn't as up to scratch as it could be. I personally welcome that subtle warning to improve my exception handling stack.

share|improve this answer

No, it's something I've gotten over several years ago. And remember there is no need to panic, the alarming would be if you did not see it (and the user did, with program crashing and all).

share|improve this answer
+1 I've gotten so that I want to see one, so I know that there's a problem I know about, not one no one can find. –  Michael K Nov 12 '10 at 13:22

Stack traces are the bomb. I love them so much, I've written error handlers to create them when coding in languages that don't give them to you easily (e.g., assembler, C). And my favorite C# statement is throw - I never write code that generates error messages any more, I throw an exception instead and let it percolate out and possibly become an error message. Sorta reminds me of an MVS ESTAE exit :-)

share|improve this answer

A stack trace is probably the single most helpful thing you can get to help you identify what went wrong and where. A nested stack trace like you can do in Java collecting local variables on the way up giving you context just makes it even more useful.

Much scaffolding is being done simply to ensure that the exception is brought through the jungle of networks, firewalls, email services to the desk of the responsible developer unscathered. They are THAT important!

share|improve this answer

I like seeing Segmentation fault the first time I try to run a program after writing a bunch of code. It confirms my assumption that it probably won't work perfectly the first time.

When hundreds of lines of untested code do end up working perfectly, that's scary. Not because it confirms the existence of ghosts, but because it doesn't force me to look over my code again, make sure it's correct, and understand why it's correct. Believe it or not, it's possible, if not common, to write a program and not understand how it works.

share|improve this answer
+1 for second paragraph! –  k25 Dec 23 '10 at 16:48

I work on a straight C codebase, so we don't see stack traces without core dumps (or at best a sigabort). That said, when I first started writing C I was a bit afraid of seg faults. Now, I view it as a good way to clean up pointer confusion.

share|improve this answer

I love stacktraces (in Java! C#! Ruby!): they are clear and explain exactly where the problem is. Where=what, give or take a few tries at poking around to figure out who the null object is :).

But now that I work in a real language -- Objective-C -- where nulls are okay yet most times the program crashes you just have NO idea where what happened happened [not a typo], even with the debugger (and stacktrace) to assist, I am, for the first time ever, kind of terrified. Terrified where there is no stacktrace, or it doesn't indicate a clear place in your code...

Regarding stacktraces in languages where you ALWAYS get a stacktrace with an uncaught exception, there's nothing to be terrified of. Over 10 years ago another dev told me, "read the f**king stack trace!" And since then, I have grown to love them, and started paying attention to them.

share|improve this answer

The only thing that scares me are programs that don't behave as expected with no apparent clue as to why.

This is usually the result of accidentally counting on undefined behavior that happens to work consistently most of the time.

Stack traces, segfaults, FPE's .. all easily analyzed and corrected. Operating on a dangling pointer with 2 - 3 bytes most of the time? Darn hard to find.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.