
Bug #915: Solved - ingve
https://nedbatchelder.com//blog/202001/bug_915_solved.html
======
alpb
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.

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

~~~
swebs
I think the biggest dragon to slay would be the legendary GTK issue #233 which
has been open for 15 years and has become sort of a meme by now. So many
people try to solve it but fail since it requires intricate knowledge of the
framework.

[https://gitlab.gnome.org/GNOME/gtk/issues/233](https://gitlab.gnome.org/GNOME/gtk/issues/233)

~~~
Aeolun
I dunno, but the GTK devs do _not_ seem like a sympathetic bunch there. In
fact it looks downright toxic.

After reading an issue like that I would be very hard pressed to motivate
myself to contribute anything.

~~~
mmmrk
My impression is the opposite: random users demanding that some devs spend
their time on a tricky corner issue and getting angry about it. After reading
their comments, I'd be very hard pressed to motivate myself to work on it.

~~~
swebs
Well one person actually provided a solution, but then one of the maintainers
just dismissed it because it was on Github, then locked the issue.

~~~
mmmrk
It seemed unclear that the patch addressed all the issues raised in the
ticket, and looking at random patches still requires dev time. It is a
different story when someone else actively works on getting it upstreamed and
working on resolving any issues. It's about who volunteers to do the hard
work.

Given that no one stepped up to do it yet and random users chimed in with
aggressive and/or unhelpful noise, locking the issue was adequate.

I find it concerning how much abuse GNOME devs get, and I can completely
understand that they respond like this.

~~~
Aeolun
Uh, as far as I can see, all the hard work is done, and has been merged into
other forks. The Gnome devs just ideologically disagree. The whole ticket is a
perfect example of “don’t let perfect be the enemy of good”.

------
hinkley
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 assume a 5th grade reading level for math (which
consists of +-x/), and use parentheses for _everything_ else. Especially if
you think yourself to be clever (narrator: he did).

~~~
nneonneo
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 ==.

~~~
Cthulhu_
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".

~~~
chopin
Implicit casts are both convenient and evil. JavaScript deserves its own place
for it.

I've never understood why any language does this. To save a few keystrokes?
Code is much more read than written.

~~~
Izkata
Javascript and PHP deal with HTML, where input forms can only request text*
but are often used for numbers, so the conversion rules are an attempt to
automatically treat numbers as numbers instead of forcing programmers to
always do the conversion themselves (as other frameworks rely on instead).

With this kept in mind, I've personally found almost all the implicit
conversions in both languages to be intuitive.

* You can limit the values to numerics, and nowadays use attributes to handle javascript, but that wouldn't help PHP where it gets encoded to querystring anyway.

------
lilSebastian
Previously:
[https://news.ycombinator.com/item?id=22028581](https://news.ycombinator.com/item?id=22028581)

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

~~~
gowld
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_ ?

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

------
gigatexal
2020 is the year of good vibes so far. The cool story of the reader getting
hired from his experiences being featured on HN and now this.

------
kjksf
This bug, the HN thread and how hard it is to fix
([https://bugs.python.org/issue39318](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 said "oh yeah, that's because this code is obviously
wrong". It took someone skilled enough to script gdb to figure out the buggy
interactions.

So the next time someone makes fun of `if err != nil`, send them the buggy
implementation of tempfile.NamedTemporaryFile and ask them to spot the bug.

Also, KeyboardInterrupt should not be an exception. It's a signal, not an
error or exceptional situation that code wants to report to the caller. But
once you have a hammer, everything looks like like a nail. In addition to
making the code impossible to reason about, no-one can agree what exactly is
an exception so they randomly commingle expected errors with exceptional
circumstances and, in case of Python, out-of-band signals.

("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?)

~~~
deanCommie
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 exception. It's a signal, not an
> error or exceptional situation that code wants to report to the caller.

OP doesn't mention anything about KeyboardInterrupt, but I'll bite.

Some languages like C# make "Events" a 1st party citizen, making it really
easy to write non-sequential code and handling such events.

Most don't, so when people want to GUARANTEE a caller handles a particular
signal, they use the Exception tool because it posesses the necessary
qualities.

"Using Exceptions as flow control" is a well-known anti-pattern but even anti-
patterns have their use in exceptional circumstances.

> ("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?)

I'll concede this one point. In-memory utility methods shouldn't throw
exceptions when a useful error code would be just as good - it keeps code
cleaner without trycatch blocks. NumberFormatException is my bane in Java.

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

~~~
rumanator
> Exceptions as flow-control is normal in Python.

Perhaps it's high time that problem was solved?

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

~~~
rumanator
> This isn't a problem

It actually is. Abusing exceptions as the normal control flow is a crude anti-
pattern. Obviously the normal flow of control is not exceptional behavior.
Therefore, abusing exceptions and exception-handling mechanisms to implement
the happy path is simply wrong at many levels, from conceptual to practical,
and in the end actually cause problems and hard to find buga such as the
problems described in this bug report.

------
yhoiseth
This made me laugh out loud:

> Hacker News can be helpful, in spite of the tangents about shell
> redirection, authorship attribution, and GitHub monoculture.

------
egdod
That was quick.

