4 ms·
And you know what? In my experience it's not less robust. So my code hasn't had every possible failure case thought through and explicitly handled in advance.
by eftpotrm 15y ago
And you know what? In my experience it's not less robust.
So my code hasn't had every possible failure case thought through and explicitly handled in advance. That's good. Firstly some of those errors are so rare they'll almost certainly never occur in my program's lifetime; by not having to handle them explicitly and individually I save time and money. Secondly I can guarantee that, no matter how good I think I am, the program will eventually find a way of crashing I'd not considered; this approach gives me a clean means of handling unforeseen errors as well.
A bad programmer can write bad code in any pattern and with any tools. A bad C programmer using return values can create so many different standards for how to handle errors that you might as well get out the divining rods to read the code. Personally, done right (as with anything) I happen to like try...catch.
- dasil003 15y agoJust because you think a certain error will never happen for the lifetime of a program doesn't mean that not explicitly handling it is equally robust.
- eftpotrm 15y agoNo, I agree, but there's a cost/benefit calculation to be done. Plus it's not like the try...catch solution that doesn't explicitly handle the error will blow up and destroy everything; if the program is properly designed it should merely degrade onto the path of general handling, log the failure and halt whatever was being done.