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

71–80 of 111 posts

Re: Bug #915: Solved

#71

Post by masklinn »

thaumasiotes wrote: post #64
masklinn wrote: post #56

Earlier quoted context omitted.

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 acce…

> This isn't really different from the multiple values approach.

If you ignore most of what I said then it’s not.

> Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.)

It’s neither type-safe nor unambiguous.

> This works

For low value of works. Which I guess is all you can ask for in a dynamically typed langage (eg Erlang uses this pattern to fairly good effect, but it has very good support for it).

But it should not be confused with an actual solution to the issue. It can make things less bad (again given good support for this pattern which Python does not have), not actually good.

Re: Bug #915: Solved

#72

Post by thaumasiotes »

masklinn wrote: post #71
thaumasiotes wrote: post #64

Earlier quoted context omitted.

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 acce…

> This isn't really different from the multiple values approach. If you ignore most of what I said then it’s not. > Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) It’s neither type-safe nor unambiguous. > This works For low value of works. Which I guess is all you can ask for in a dynamically typed langage (eg Erlang uses this pattern to fairly good effect, but it…

> It’s neither type-safe nor unambiguous.

How'd you get here? It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe, and it's fully unambiguous.

Re: Bug #915: Solved

#73

Post by chopin »

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

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.

Re: Bug #915: Solved

#74

Post by julienfr112 »

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.

That's not funny, that's the community being nice ! I don't want to live in a world where being nice is so rare that it ends up being funny.

Re: Bug #915: Solved

#75

Post by rocqua »

chopin wrote: post #73
Cthulhu_ wrote: post #68

Earlier quoted context omitted.

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

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.

In most cases, up or down casting 32 and 64 bit integers would be a shitton of work that barely adds anything. A similar case could be made for casting ints to floats (i.e. 2 + 3.1 should just work).

Beyond that though, most implicit casts are just bad.

Re: Bug #915: Solved

#76

Post by rocqua »

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.

You could get a very similar issue in C++ where a destructor closes an FD that was already erroneously closed by an earlier call to a member function due to an exception.

The issue here is a bug in resource management. The specific bug was caused by an exception that shouldn't be caught still being caught. Which erroneously messed with resource management.

Re: Bug #915: Solved

#77

Post by swebs »

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.

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

Re: Bug #915: Solved

#78

Post by simion314 »

masklinn wrote: post #55
simion314 wrote: post #18

Earlier quoted context omitted.

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.

I still do not understand, I did not see where the exception caused the issue in this case, you can have bugs with error codes that are not checked and that blow up much later so I am confused by your vague response (maybe you prefer checked excpetion so you don't ignore problems, I prefer those because they force correctness over developer comfort).

Re: Bug #915: Solved

#79

Post by simion314 »

rocqua wrote: post #76
simion314 wrote: post #18

Earlier quoted context omitted.

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.

You could get a very similar issue in C++ where a destructor closes an FD that was already erroneously closed by an earlier call to a member function due to an exception. The issue here is a bug in resource management. The specific bug was caused by an exception that shouldn't be caught still being caught. Which erroneously messed with resource management.

I did not see that in the snippets I will try to find the section, was the bug in the code that was catching the exception or it was thrown by mistake. I agree that is a resource management issue and you often make this kind of bugs when you try to reuse objects (for performance reasons most of the time)

Re: Bug #915: Solved

#80

Post by taneq »

dredmorbius wrote: post #43
dang wrote: post #5

Earlier quoted context omitted.

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.

An entomology etymology ontology difficulty-novelty hierarchy?

Bravo!
Post reply on HN