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

21–30 of 111 posts

Re: Bug #915: Solved

#21

Post by joshuamorton »

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…

> ("randomly" as in: why is "open file" throwing an exception when file doesn't exist but "find substring" returns -1 when substring doesn't exist?)

Because there can be lots of ways for `open` to throw an exception (encoding issues, not found, permissions, etc.). The underlying open syscall has 39 error codes. Python adds a few more failure modes atop that. I'd much rather deal with named error conditions than deal with return values -1 through -50.

Find substring can only fail in one way.

Re: Bug #915: Solved

#22

Post by larkost »

rumanator wrote: post #17
CaptainMarvel wrote: post #16

Earlier quoted context omitted.

Exceptions as flow-control is normal in Python. It’s used all over the place, e.g. generators with StopIteration.

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

Re: Bug #915: Solved

#24

Post by the_jeremy »

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.

I don't know about "personal repo". My employer uses this tool to help test production code.

Re: Bug #915: Solved

#25

Post by ken »

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…

> a pretty good argument against exceptions

Every time there’s a subtle bug with 7 contributing factors, people pick the one which is caused by a design decision they happen to hate, and place all of the blame squarely on that one.

Re: Bug #915: Solved

#26

Post by nneonneo »

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 compilers that are nice enough to have these warnings.

As a bonus, different languages handle precedence of &,|,^ differently: Python, for instance, binds & more tightly than ==.

Re: Bug #915: Solved

#27

Post by sicromoft »

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…

Terminology nit: Flow control is not the same as control flow (which is sometimes referred to as flow of control... yeah it's confusing).

https://en.wikipedia.org/wiki/Flow_control_(data)

https://en.wikipedia.org/wiki/Control_flow

Re: Bug #915: Solved

#28

Post by gowld »

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 ?

Re: Bug #915: Solved

#29

Post by codezero »

dang wrote: post #5
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.

There's a power-law dropoff when it comes to follow-up submissions, since the hivemind craves novelty. But it would be fun to try. Maybe it could become a thing: Bug HN! The trick would be to make the bugs interesting: weird or hard, preferably both.

Bug HN might become a huge hobby for me if people follow through on that.

Re: Bug #915: Solved

#30

Post by sefk »

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.

Part of the reason this got a good response is due to Ned himself. nedbat@ has a great reputation in several communities. Also he showed his homework. And then posted with a good, tight repro case.

Fun to see the problem and the solution. Thanks Ned and thanks HN.

Source: have seen nedbat@ in action.

Post reply on HN