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

61–70 of 111 posts

Re: Bug #915: Solved

#61

Post by Dylan16807 »

winstonewert wrote: post #36
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…

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…

> how would they would have made the error easier to spot?

There was a try block with two function calls, and it seems like the author assumed only the first function call could throw.

With return-based errors, the error handling wouldn't implicitly be shared between the two functions. The author would write the handling for the first function, and then they would notice the second function could return an error state too. Then they might write a correct handler, or at least we should expect them to say "this can't happen, so panic". This bug would have been trivial to fix if it panicked instead of corrupting fds.

Re: Bug #915: Solved

#62

Post by read_if_gay_ »

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.

You could argue that HN, too, is passive entertainment. Many posts are exactly “a novel problem someone else dealt with”.

Re: Bug #915: Solved

#63

Post by thaumasiotes »

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…

> 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.

No, this isn't a solution. This is like terminating C strings with 0 characters, or terminating TSV fields with tabs. It sounds like it makes sense, until you ask "what if the terminator occurs within the data?"

Eventually someone's going to need to store undefined. It's no different than null. If it were a competence issue (which it isn't), we'd be saying that storing null in the hash table was a mistake, not something to work around with null2.

Re: Bug #915: Solved

#64

Post by thaumasiotes »

masklinn wrote: post #56
depressedpanda wrote: post #52

Earlier quoted context omitted.

> 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.

This isn't really different from the multiple values approach. For example, python could have table accesses return (None, True) for a None value that was present, (None, False) for a value that wasn't present, (5, True) for a 5 value that was present...

Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) This works, but it's unpopular because it makes every table access more difficult.

Re: Bug #915: Solved

#65

Post by mkl »

gjs278 wrote: post #23

godawful title. I refuse to read this. put a fucking description of what software project this is.

It's a followup to a story that got nearly 600 votes two days ago and spent a long time on the front page, so most of us are well aware of the context, but which project it is is beside the point. The bug was interesting and the debugging and conversation about it was interesting. https://news.ycombinator.com/item?id=22028581

Re: Bug #915: Solved

#66

Post by Cthulhu_ »

AdmiralAsshat wrote: post #10
alpb wrote: post #4

Pretty funny how the entire HN rallied together to solve some github issue on someone's personal repo. I'll try posting some of my bugs here to see if it'll work for me as well.

Soon: "Hacker News Code Review As A Service"

Didn't StackOverflow already have that?

Re: Bug #915: Solved

#67

Post by Cthulhu_ »

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…

> Especially if you think yourself to be clever (narrator: he did).

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

        — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.

Re: Bug #915: Solved

#68

Post by Cthulhu_ »

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…

That should give a warning at least because it (and this is probably a C thing) treats or implicitly casts a boolean true / false to a 0/1. You shouldn't be able to do PORTA & true.

One more for my list of "why I don't like C".

Re: Bug #915: Solved

#69

Post by minitech »

larkost wrote: post #22
rumanator wrote: post #17

Earlier quoted context omitted.

> Exceptions as flow-control is normal in Python. Perhaps it's high time that problem was solved?

This isn't a problem, it is a design decision that you evidently don't like. There is a difference.

As a fan of Python, I agree that it’s a problem, and probably one of Python’s worst design decisions. It doesn’t achieve anything over sentinels, and results in lots of potential for hidden bugs (especially in the case of __getattr__, and before PEP 479). Comparison overloading even does use NotImplemented instead of an exception.

Re: Bug #915: Solved

#70

Post by bigpeet »

Cthulhu_ wrote: post #68
nneonneo wrote: post #26

Earlier quoted context omitted.

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…

That should give a warning at least because it (and this is probably a C thing) treats or implicitly casts a boolean true / false to a 0/1. You shouldn't be able to do PORTA & true. One more for my list of "why I don't like C".

Depending on what version of C you are using, there are no "boolean" values.

X != Y returns an integer value, no "implicit cast" required for &.

Post reply on HN