Coders at Work on finding and preventing bugs (2015) | Hacker News Reader

Coders at Work on finding and preventing bugs (2015)

benkuhn.net

17 pointsluu5 comments

I have a pattern that's working really well for us in the codebase, which I call `recover`.

Anywhere where you're tempted to crash because it's not possible, I add

    recover debug_string debug_values return_value

Recover prints a stack trace, notifies Rollbar, and then continues with the return value. As a result, we see whatever is going wrong with the code, but the program doesn't crash on users. And since we're using OCaml (strongly typed), we end up having decent guarantees of safety.

Works pretty well for us.

This sounds similar to C++'s exception-mechanism, on which the C++ community seems split on whether it's good or not.

Are they any noteworthy differences?

All error handling is fundamentally the same. I think this one is as far from exception handling as possible while still being error handling.

Has anyone had success (or failure) in the real world with enforcing preconditions, postconditions and invariants? Has this caught bugs faster, reduced side effects and helped ensure overall correctness? Or has it lead to more overhead and longer development time without much to show for all the effort?

https://en.wikipedia.org/wiki/Design_by_contract

https://en.wikipedia.org/wiki/Class_invariant

I remember doing this in one of my first programming courses, way too early to look at it with respect to any real-world usage.

I wonder if it's still useful in combination with async/await.

Reply on news.ycombinator.com