Ask HN: doesn't runtime exceptions and unit tests share the same goal?
I still see many programmers guarding runtime errors using "ifs". Which is ridiculous and leads to programs very hard to debug. Which then kind-of leads to the use (and importance) of unit tests. Any thought on that?
5 comments
> Which is ridiculous and leads to programs very hard to debug
What's the alternative in your opinion? Let's say you're trying to open a file. It can fail. You've got to check this.
What's the alternative in your opinion? Let's say you're trying to open a file. It can fail. You've got to check this.
Couldn't the ifs have other purpose, such as branching to perform other operations in those cases?
Also, consider that if the entire block isn't wrapped in a try/catch, those ifs are guarding against runtime errors which would crash the program for the user.
Although I do see unit tests making use of exceptions in their decision to pass/fail, it's not the only way to write a unit test-- sometimes you test for value, etc.
Also, consider that if the entire block isn't wrapped in a try/catch, those ifs are guarding against runtime errors which would crash the program for the user.
Although I do see unit tests making use of exceptions in their decision to pass/fail, it's not the only way to write a unit test-- sometimes you test for value, etc.
Can you give an example and how you'd re factor it. I'm having a hard time visualising what you mean.
I have seen code that catches any exception and returns false. That is annoying although for different reasons.
I have seen code that catches any exception and returns false. That is annoying although for different reasons.
How does the existence of a unit test suite, no matter how good, preclude against a runtime error?
You sound like a great candidate for Erlang!