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

> I've found that a lot of disagreement about ways to implement a feature can be solved by keeping this in mind.

I dunno, the usual reactions I get are more in line with the comments on this Stack Overflow post: http://stackoverflow.com/questions/43377533/should-python-er...

For whatever reason, making the case that code that actually performs some useful computation should be closer to the exception rather than the rule tends to result in people completely losing their shit.



I think the issue is that people don't want overhead. I don't want to wade through 12 lines of useless try raises to get my work done. I want to be able to enumerate the exceptions when I need them. For example, I may want to call my_function.possible_exceptions, but there is an issue here as well, two exceptions may be raised with different messages, so the class of the exception alone is not an acceptable identifier of what the exception is. Even attempts to create, say, a global register of unique exceptions would fail because of how dynamic a language like Python is.

In general readability of code has more to do with something like this:

    valid_filename = filename.ends_with? ".txt"
    return File.open(filename) if valid_filename
Versus something like this:

    return File.open(fn) if fn.ends_with? ".txt"
The former uses a longer variable that clearly shows what it is and reduces the mental overhead of having to figure out why we're returning (because the file is valid, we're finished with this function as intended).




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

Search: