5 ms·
it's a real trade-off. i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. for server software it's death. (yo
by dilap 8y ago
it's a real trade-off. i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. for server software it's death. (you need to service the request to the best of your ability, and make sure that you are handling any failures in the best possible way.)
- bigato 8y ago> i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. Your users probably don't think so
- dilap 8y agoit can be not-so-bad, because it's something like, "oh, i passed in the wrong file" or "oh, that menu item is broken" or something like that. you as a user are entirely in control of the inputs & the state is usually just a file or two, so it's easy to just try again until things work. but for something running on a server somewhere, many inputs are beyond the user's control & the state is long-lived and fragile (if my HN or FB account gets somehow b0rked, that's a serious problem for me), so it's important to handle all possible error conditions in the best possible way. in my experience this is something exceptions make very hard to do. (& i would still prefer explicit error handling even for front-end software, but i think the argument for exceptions is at least stronger there.)