undefined | Better HN

0 pointsmagicalhippo3y ago0 comments

> When you read code, you have to treat all conditions symmetrically and equally likely

Pretty sure I don't do that when I read code. When I see "list.add()" I don't consider running out of memory and the operation failing equally likely to the list being added to. And if it did, in 99.99% of the cases I'm fine with it just bailing, because there's not much else to do at that point.

I agree that using exceptions for what could be considered normal conditions is not great. Trying to open a file that doesn't exist isn't by itself an exceptional incident. The calling code might consider it an exception and decide to raise, but the IO library shouldn't.

0 comments

hnaccount_rng3y ago

> Trying to open a file that doesn't exist isn't by itself an exceptional incident. The calling code might consider it an exception and decide to raise, but the IO library shouldn't.

This is a way of thinking that I don't get. Yes it's fine that an IOLibrary has to be able to handle a FileDoesNotExistError condition. But from the caller POV: I clearly instructed you to open a file of some description. I expect you to return to me a handle for said file. Everything that does not match that expectation is exceptional (to the caller).

And it is that violation of expectations that is communicated by (Python's) exceptions.

magicalhippoOP3y ago

> Everything that does not match that expectation is exceptional (to the caller).

No. If you want to read some data from a file if it exists, and continue merrily along if it doesn't, then you cannot simply check if the file exists and then try to open it. That would lead to a race condition. The file could for example be deleted in between the two calls.

The only proper way to handle that is to try to open the file, and if the result of that is FileDoesNotExistError then you continue along merrily.

If the file the caller tries to open is a settings override file, say, then it's not exceptional that the file does not exist.

acoard3y ago

> Everything that does not match that expectation is exceptional (to the caller).

Sure, but saying "open this file" and having the response "nothing here, boss" is not exceptional. It's pretty normal. Isn't that just one of the two obvious options when you try and open a file? To me, exceptional would be something like "this file was open and now it's deleted."

j / k navigate · click thread line to collapse

0 pointsmagicalhippo3y ago0 comments

> When you read code, you have to treat all conditions symmetrically and equally likely

0 comments

hnaccount_rng3y ago

> Trying to open a file that doesn't exist isn't by itself an exceptional incident. The calling code might consider it an exception and decide to raise, but the IO library shouldn't.

And it is that violation of expectations that is communicated by (Python's) exceptions.

magicalhippoOP3y ago

> Everything that does not match that expectation is exceptional (to the caller).

The only proper way to handle that is to try to open the file, and if the result of that is FileDoesNotExistError then you continue along merrily.

If the file the caller tries to open is a settings override file, say, then it's not exceptional that the file does not exist.

acoard3y ago

> Everything that does not match that expectation is exceptional (to the caller).

j / k navigate · click thread line to collapse