4 ms·
I dislike exceptions, because they are magic. You can't tell what exceptions the piece of code you're calling will throw. It can also easily change with a libra
by hawski 9y ago
I dislike exceptions, because they are magic. You can't tell what exceptions the piece of code you're calling will throw. It can also easily change with a library upgrade.
I like exceptions, because they are magic. While prototyping or for small utilities it's perfectly OK to "crash" on any error - nice error message can help then.
However I prefer when the final version handles all errors explicitly. I want to see it documented in code that error handling was not forgotten and it was deliberate to push certain errors back the stack. Of course it can work with documentation telling that this library never catches any errors, but it will put the burden on me. I also prefer to have a code, because documentation, more often then not, is lying.
Having written all that, I'm wondering how exceptions work with Python's "Explicit is better than implicit". I guess in case of exceptions this rule has lower priority than some other rule that priorities simple looking code. That would align with my use of Python - strictly for one off utils and prototypes.
- Terr_ 9y ago> You can't tell what exceptions the piece of code you're calling will throw. Which is why I actually like Java's Checked Exceptions, at least for public-API purposes. It's really the exact same principle as having a contract for functions' return-values.
- _pmf_ 9y agoI like them, too. You can easily opt out of the "checked-ness" by wrapping it in a non-checked exception, so the argument that it pollutes your application is just a non-issue for me.
- AstralStorm 9y agoThis would have to work like the deprecated throw() statement and change the mangling scheme so that no linking errors would occur. I'm pretty sure it was proposed more than once in the standard committee.
- oselhn 9y agoI worked on huge old codebase. Mostly int return values were used as error indicator. But there were at least 3 non-compatible error enums (OK/ERR, PROCESSED/UNKNOWN/ERR, 1/0). Those enums partially used the same int values so you had to make sure to not mix them up (as you pointed documentation was frequently incorrect). Usually it took me several hours to check that error handling in some function is consistent or determine which of those enums is used. You can make huge mess with explicit error handling too.