Do you still panic when you see a stack dump? Why?

Question

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?

Why?

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

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 :-)

Answer 7

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!

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.