Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

Yeah, nah. I’m not typing 5 levels of “structs” for one or two properties I want.

I'm not sure what you're after, then. You have basically the same safety problems in Ruby and Python dealing with nested JSON; the thing you seem to be bothered by is that Go makes it possible to get extra safety here.

I’m not after anything. Why do I need “safety” from a web response? You should be liberal with what you’re accepting from a service.

What “type safety” could you possibly hope for from a system you don’t control?

> Why do I need “safety” from a web response?

I’m not even sure where to start from that. Responses provided to an HTTP request are one of the most obvious places where enforcing structure and type safety is clearly a win.

Go's nested struct syntax actually makes doing so quite nicer than Rust :)

Yeah, the formality of embedded structs can lead to some very verbose bloat. And it obviously only works on very reliable payloads.

What's the solution for an unreliable payload? When things aren't where you expect them in a JSON blob with a Python Flask app, your app also just breaks on that input.

    try:
      val = input['foo']['bar']
    except KeyError, TypeError:
      raise HttpErrors.BadRequest

Can someone explain to me why python uses try/except so often? I see that promoted as a solution instead of;

if 'bar' in input['foo'].keys(): val = input['foo']['bar']

Generally, exceptions cause code to run slower and I feel like in any other language is considered bad practices.

I never understood why Python promotes EAFP vs LBYL. Both performance and accuracy wise, checking before doing is safer and faster performance.

Your example will throw a KeyError if "input" doesn't contain "foo", and an AttributeError if "foo" is some unexpected data type that doesn't have keys().

Well, firstly input.get("foo", {}).get("bar", default) is a bit nicer, imho.

Python exceptions are only slower on the exception. They are almost exactly the same speed on success.

LBYL forces you to look for all the ways in which you might leap. EAFP lets you handle even unexpected conditions. The classic use case is checking if a condition exists, then doing the thing, except the condition changed between check and run. So you gotta catch anyways.

I've been moving away from this actually and towards a rust-like Result[T, Exception]. I'm using the package called "result". For fastapi api_request -> handler -> some_func_chain -> return response_to_client patterns, if something barfs, you normally get a 422 and useless "Internal server error". It's far simpler imho to map over some Results and then pack the error(s) into a more useful response.

Also testing is just a lot simpler.

https://pypi.org/project/result/

You just generated a 502, and spent a bunch of extra lines doing it. The 502 is bad, and if that's all I need to do, I get that almost for free from net/http's panic handler. It sounds like you don't actually have a problem here.

I think that was more of an example. There are lots of ways to fail gracefully when you don't have the data you want in the dict.

Right, which is why json.Unmarshal returns an error, and why map lookups return an extra `ok` value in Go.

It would be a lot more than 4 lines in Go though. Either the struct definition, or a lot of `if !ok return error`. Especially once the nesting gets deeper.

I'm pretty sure it would just be an `if err != nil {http.Error(w, err.Error(), 501); return }`.

one of these for each nesting level.

I kept the example simple, of course I could now customize the error message further (or take some other sensible action). Note that I returned a 400, not a generic 502 here. If I didn't care at all, I wouldn't need any extra lines. Does the panic handler send a response at all, or does it just drop the connection?

Also, in Go, using panic/recover is considered unidiomatic. You can use it like an exception system, but it's not what you're supposed to do.

I'm not suggesting that you would build a custom exception recovery system; I'm pointing out that net/http, which is definitionally idiomatic, already has that recovery mechanism.

I believe that that recovery mechanism isn't supposed to be routinely triggered just due to bad user input, and that code that does so would be considered defective.

It's doing almost literally the same thing as the Python code upthread. Just, with less code.

What solution? There is no solution. The web just works that way.

You receive some bytes and you do stuff with them. Any other expectation is a farce.

Is a property missing after serialization? Can you even serialize it? Maybe a different status code returns a different mime type! OK, whatever. That’s not always an error, nor is it remotely “exceptional.”

I mean, I agree. That's why I'm sort of confused about what the problem is here. Yes, you can get unreliable inputs. Most apps barf on them, even if they think they don't. The barfing mechanism is pretty much the same everywhere.

Reply on news.ycombinator.com