Hacker News Reader

Comment by ljosifov | Hacker News Reader

+1. I have had my ASSERT defined to 1) signal the program to pause it, 2) start gdb (or ddd), 3) attach to the pid, 4) tell gdb what the binary is, 5) wait on me most of my programming life. No idea why this is not the default.

View on HN

most programs are not run interactively, so dumping a core is a more sensible default.

You want the program to hang indefinitely in production because it hit an assert?

You want your program to continue executing in an undefined, probably erroneous, possibly destructive state because you ignored an error?

And this isn't theoretical. I've seen ignored errors do damage in the past. Was infuriating to see that we had set a top-level exception handler in our server that just logged and kept going. We had a couple tables in our database trashed because of that and ended up having to restore from the nightly backup, losing everything that was changed that day.

What do you you think the default behavior of an assert is? If you are turning them off, then you get what you describe, which is not what I am advocating.

Assertions are compiled out of 'production' (non-debug) builds.

The same holds true of Python if you run it with the optimize flag/environment variable, leading to any number of hilarious bugs because people cause side-effects in their assert calls.

Compiling out assertions in production is like taking your seat belt off when you leave the driveway. Seriously, in my experience, all the interesting stuff happens in production. We deploy two builds, app.debug and app.release. We run generally run app.debug unless there are performance issues, but even in that case, we sometimes run it just to make sure nothing shows up.

Same here. And it's insignificant cost to have a terminal attached to the process. So instead a mere stack trace and local vars on the stack in the core dump, I actually have the entire process, the heap with all the objects, all file descriptorsabd various OS handles and state, to interrogate. The program would have been running many hours, sometimes days, up to this point. Why would anyone throw all that valuable info away by default.

Of course - crash, hang, core dump, whatever, just do NOT continue as if nothing happened. My programs are in control of much $$$, I would be horrified if a program was to continue running in undefined state. Errors and warnings are issued and handled by operations - that's part of the program logic. But if an assert is triggered then all bets are off, best to stop 99.9% of the time.

Reply on news.ycombinator.com