Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This doesn't sit well with me. Who is to say what's catastrophic and what's not? Should I use all libraries in fear because passing a nil pointer or an improperly formatted date may cause it to terminate the program with no recourse? Suddenly every library is a ticking time bomb with a scorched Earth policy for things it doesn't like. How am I to know what's going to cause my valuable program to simply die in the middle of the night? Look at the outdated/incomplete documentation? Pore over the complex code (if it's even available)? Now not only do I need to litter error value checks everywhere, but I also need to preemptively sanitize all input to any library calls I make and pray that I haven't missed something. This is simply trading one problem for another.


That's a potential issue with any language, I believe. In Go you can recover() from what would otherwise be a termination. For example, I have a function that grabs and parses RSS feeds. If my program is fed junk by the remote site, I don't want to terminate, I want to ignore the error for that feed (after logging it). To do this I recover() from any error at the feed level.


Is your opinion set by the article's assertion "panics are always fatal"? Because that is incorrect, there are good mechanisms for handling them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: