Hacker News Reader

Comment by brian-armstrong | Hacker News Reader

Study the idioms of whatever language you are using. If you're writing production code, consistency is everything. Don't write anything surprising or clever - you'll just paint yourself into a corner later, and it'll be impossible to maintain. Boring code is good code.

Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously

View on HN

Think about your error handling best practices. Mine are:

1. Re-structure your logic so the error cannot happen

2. If you can't do 1, recover from the error silently and continue on with the program

3. If you can't do 2, handle the error gracefully and notify the user of what state is changed, letting them choose whether or not to continue

4. If you can't do 3, inform the user of what happened and ideally provide the user corrective action they can take, then exit cleanly with an error code

5. If you can't do 4, exit cleanly with as descriptive of an error code as you can

6. If you can't do 5, you're probably faced with crashing or exiting with some unhandled exception. This is a bug that should never go into production.

Always be looking for opportunities to move your code up that hierarchy. Moving every 6 to 5 is my personal bar for barely acceptable quality. 4->3 is usually a big win (basically anything that prevents the program from exiting).

"2. If you can't do 1, recover from the error silently and continue on with the program"

I think that defensive programming is the worst way of dealing with errors. You are now silently diverging from your business requirements by making up data.

Thanks for the reply. Yep, this is a topic that reasonable people can disagree about. I suppose I could add "if there's no loss of user data, recover from the error silently and continue on with the program". An example of #2 would be a network connection failure that can be retried without consequence to business logic.

Please, everyone who thinks, "I just expect correct inputs" take note of part two. I've had so many discussions with colleagues about that "Why don't you check for null pointers and give an error message?" "I think it's perfectly fine to just crash with a null pointer, I don't expect null pointers."

That attitude hurts everyone who has to support what you write.

edit: Reformatted as a habit "Make sure whatever you write can be supported without unnecessary headaches."

Only if a.) you can do something to recover from the null pointer or b.) you can provide more information about its cause than you could recover from an ordinary stack trace. Otherwise you're just adding code without changing the ultimate result of the NPE: a debugging session.

Assertions, however, are great. If you can force the program to throw that NPE closer to the point where it actually illegitimately became null, the debugging session becomes much shorter. Null-safety in the type system (like with most modern languages: Swift, Haskell, Kotlin, Scala, Rust, etc.) is even better.

I have almost never seen a program where you have neither a nor b, but I agree - if you are in a situation where neither a nor b apply, don't do anything.

And: Using a different language is always a great idea, but often not possible.

This! I especially see this problem in Java, where IDEs always suggest catching an exception. Like a dog chasing cars, you really should think through what you're going to do when you catch one. I've wasted a lot of time debugging problems that get masked over by try/catch only to pop up at some later point in a seemingly unrelated part of the code.

This is what Martin Fowler refers to as the Tolerant Reader pattern. https://martinfowler.com/bliki/TolerantReader.html

Code should tolerate all sorts of bad inputs. Code should produce pristine outputs.

Just like being a model member of society

I think I read somewhere that Jonathan Postel (Internet pioneer) also had a rule advising that.

Googled and found it:

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

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

"In his lifetime he was known as the "god[2] of the Internet" for his comprehensive influence on the medium."

Whenever I need to know any idiom, I like to go to http://idioms.in/ website at the drop of a hat.

"Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously" Wisdom.

Reply on news.ycombinator.com