Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug #915: Solved

nedbatchelder.com

Post reply on HN
Print view View original

51–60 of 111 posts

Re: Bug #915: Solved

#51

Post by kortilla »

gowld wrote: post #28
ehsankia wrote: post #7

So the final answer is basically, there's nothing the author can do. The problem was half with the user's code mocking with internals, and half with downstream library not cleaning up properly.

Mocks are terrible and should almost never be used, but this wasn't a mock. This was a monkeypatch. Does anyone expect that their software would function properly in the face of arbitrary changes patched in by untrusted third parties ?

Monkey patching is a key feature of the python mock library. Get used to it if you’re getting into python development because you’re going to come across it.

Re: Bug #915: Solved

#52

Post by depressedpanda »

thaumasiotes wrote: post #39
kjksf wrote: post #11

This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…

> why is "open file" throwing an exception when file doesn't exist but "find substring" returns -1 when substring doesn't exist? Well, first, there's more to it than that. "Open file" will throw an exception when you open the file to read and it doesn't exist. If you open the file to write and it doesn't exist, you won't get an exception because that's expected behavior. Instead, the file will be automatically create…

> The same problem is more frequently discussed in the context of hash tables. If I look up a key in a hash table and I get a null value, is that because there is no value stored for that key, or is it because null is the value stored for that key? People would like accessing the table to be convenient while distinguishing these two cases, and python doesn't allow that. You can choose from some different behaviors:

Or, you can create a second null-like type in the language, name it 'undefined' perhaps, and return that when the key doesn't exist.

Of course, that may be considered kicking the can down the road as now you will have to trust developers to be competent enough to never store 'undefined' in the hash table, which I suppose is the reason you didn't mention JavaScript's solution to the problem.

Re: Bug #915: Solved

#53

Post by masklinn »

deanCommie wrote: post #15
kjksf wrote: post #11

This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…

An extremely obscure and rare scenario that exposes a flaw with a convenient tool does not negate the value of the tool in all other cases. Are you also going to throw out all use of automatic garbage collection in languages because of a bug caused by a GC pause. Should we stop bothering with encryption because people discover weaknesses and attack vectors? Come on, man. > Also, KeyboardInterrupt should not be an exc…

> NumberFormatException is my bane in Java.

Surely that’s because of java? conversions normally throw in python and that’s no issue. So does indexing. So does str.index.

Re: Bug #915: Solved

#54

Post by masklinn »

imron wrote: post #47
winstonewert wrote: post #36

Earlier quoted context omitted.

My question is: what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using Go's `!= nil` pattern or Rust's `?` pattern. My experience is that while its true that its easy to have bugs in implicit exception handling logic, its just as easy, maybe easier, to have bugs in the explicit boil…

> Its not obvious that the error would have been easier to spot if it had been written using Go's `!= nil` pattern or Rust's `?` pattern. I like Rust's `?` operator (and Swift's `guard` statement also), but it's worth noting that the bug wouldn't have existed in Rust in the first place because the file object wouldn't have outlived the scope it was defined in.

Also and really because it’s quite hard to go and replace implementation details with code which behaves completely differently and implements an unrelated contract entirely.

Re: Bug #915: Solved

#55

Post by masklinn »

simion314 wrote: post #18
kjksf wrote: post #11

This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…

I do not see how exceptions caused the bug, seems the cause is a bug in a GC language d that is wrapping a low level code/resource and not releasing it properly.

In a langage without exceptions the file wrapper being trivial it would not have returned any sort of error condition and thus would not have been checked for it.

It is an issue of exceptions that try clauses can easily be overly broad in the amount of code they cover.

Re: Bug #915: Solved

#56

Post by masklinn »

depressedpanda wrote: post #52
thaumasiotes wrote: post #39

Earlier quoted context omitted.

> why is "open file" throwing an exception when file doesn't exist but "find substring" returns -1 when substring doesn't exist? Well, first, there's more to it than that. "Open file" will throw an exception when you open the file to read and it doesn't exist. If you open the file to write and it doesn't exist, you won't get an exception because that's expected behavior. Instead, the file will be automatically create…

> The same problem is more frequently discussed in the context of hash tables. If I look up a key in a hash table and I get a null value, is that because there is no value stored for that key, or is it because null is the value stored for that key? People would like accessing the table to be convenient while distinguishing these two cases, and python doesn't allow that. You can choose from some different behaviors: O…

The actual fix is to have a completely separate wrapper type (usually an option type) which signals in a type-safe and unambiguous manner that the key was missing.

Then you don’t have the issues of in-band signalling.

Re: Bug #915: Solved

#57

Post by masklinn »

thaumasiotes wrote: post #39
kjksf wrote: post #11

This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…

> why is "open file" throwing an exception when file doesn't exist but "find substring" returns -1 when substring doesn't exist? Well, first, there's more to it than that. "Open file" will throw an exception when you open the file to read and it doesn't exist. If you open the file to write and it doesn't exist, you won't get an exception because that's expected behavior. Instead, the file will be automatically create…

> We can solve the how-do-we-want-the-hash-table-to-behave problem perfectly by returning an invalid index when the substring isn't present, and... that's what we do.

Negative indices are valid in python. Also str.index raises.

And product types are not a good way to signal exclusive conditions.

Re: Bug #915: Solved

#58

Post by Dylan16807 »

vermilingua wrote: post #48
teej wrote: post #35

Earlier quoted context omitted.

Yep, when I sent out a call for help for a bug on HN in 2012, I got ~190 votes. When I posted the followup I got 5. It’s a little strange because for Reddit’s r/legaladvice it’s the opposite. Follow up posts can rank much more highly than the original.

One reason why that might be the case is that HN is a community of people that like to find and solve problems. Reddit on the other hand is passive entertainment, users are more interested in a novel problem that someone else dealt with.

It's something else entirely. Almost all the posts on /r/legaladvice are shouting into a void. Hopefully it helps, maybe there's some interesting side discussion...

But an update? That means there's actual feedback and conclusions! Something that's desperately lacking on that particular board.

It's not about reddit as a whole.

Re: Bug #915: Solved

#59

Post by Dylan16807 »

nneonneo wrote: post #26
hinkley wrote: post #8

The first really bizarre bug I fixed was a file descriptor bug. The code was streaming data and in some cases the app would just stop processing network packets. He or I figured out that keyboard input would temporarily unblock things. He had a compound conditional without enough parentheses in it, and one of the possible outcomes resulted in fd=1, which is stdin on many operating systems. My general advice now is to…

The very low precedence of & is the source of an unbelievable number of bugs, especially in embedded programming. For example: if(PORTA & 3 != 0) looks like it should be true if either of the low two bits is set. But actually, it only fires if the low bit is set because this resolves to PORTA & (3 != 0), which is PORTA & 1. Some C compilers will warn you about this. Embedded C compilers are not usually the sort of co…

It's a shame. C made the precedence blatantly wrong so a few thousand lines of legacy code wouldn't have to be updated.

And then everyone decides their own languages will copy it forever.

Re: Bug #915: Solved

#60

Post by Dylan16807 »

deanCommie wrote: post #15
kjksf wrote: post #11

This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…

An extremely obscure and rare scenario that exposes a flaw with a convenient tool does not negate the value of the tool in all other cases. Are you also going to throw out all use of automatic garbage collection in languages because of a bug caused by a GC pause. Should we stop bothering with encryption because people discover weaknesses and attack vectors? Come on, man. > Also, KeyboardInterrupt should not be an exc…

> OP doesn't mention anything about KeyboardInterrupt

Please go check on the original post.

Post reply on HN