4 ms·

write on the introduction it says https://build-your-own.org/database/00a_overview https://build-your-own.org/database/00a_overview Or if you see any chapter y

by vira28 3y ago

write on the introduction it says https://build-your-own.org/database/00a_overview https://build-your-own.org/database/00a_overview Or if you see any chapter you can literally see Go code.

macintux 3y ago
You're right, I missed the one place in the introduction where it mentions Golang. Other than the "if err != nil" I wouldn't have recognized the code samples. Go's error handling is a big reason I've never taken a closer look.
- bsaul 3y ago
  never understood the issue with go error handling. As soon as you start dumping exceptions as a valid error forwarding mechanism ( which seems like a totally acceptable design decision), you end up manually having to check every call you make that can raise an error, on each line. I don't really see any alternative. It also makes you carefully think about how you plan on managing errors in your codebase, which also seems like a very sane thing to enforce.
  - ikiris 3y ago
    people who aren't used to actually handling their errors get annoyed at typing return err all the time. They'd prefer an easier way to not bother dealing with them with them without outright ignoring them via _
    - alpaca128 3y ago
      I'd get annoyed too, because I know there are much simpler alternatives. Language design should encourage doing things right by making it more convenient than the shortcuts. In Rust that entire check can be a single "?" symbol. How much syntactic sugar is too much is a matter of preference, but I personally think that properly handling all errors without syntactic sugar turns into an unreadable mess because there's just a lot of things which could go wrong.
      - bsaul 3y ago
        almost 50% of the time i want to add some debugging info to the error before forwarding it one layer above, to provide more context. I think just forwarding all low-level errors is a really bad habit, and go forces you to at least think about this.
        alpaca128 3y ago
        > I think just forwarding all low-level errors is a really bad habit Why exactly is that a bad habit? In almost all situations where I return an error I already have enough context, I'm just wondering what else I'd add to that. > go forces you to at least think about this Boilerplate code definitely doesn't incentivize thinking.
        deleted 3y ago
        [deleted]
        bsaul 3y ago
        most errors you encounters are with i/o and are stupid "can't read, can't write or can't serialize". In a network environment (which is originally what go was made for) you often need to add tracing information, business-level identifiers or processing information related to your state etc. I'm currently writing a fairly complex api in go, and to be honest this really hasn't bothered me once. Not to say it doesn't exists, but with time i've come very suspicious of people complaints over go. Most of the time those complaints come from people that didn't realize they missed an opportunity to have written a much much more elegant solution to their problem.
        ikiris 3y ago
        or usually just try again with backoff.
      - ikiris 3y ago
        just returning the error isn't handling it.
  - jeremyjh 3y ago
    You don't have to trap exceptions separately on every line. You trap a whole block of code and match on the exception type to determine how to handle the problem. It isn't perfect, nothing is, but I prefer systems languages where typical failures cannot easily be ignored and yet you are not burdened with constantly thinking about it.
    - Mawr 3y ago
      > I prefer systems languages where typical failures cannot easily be ignored and yet you are not burdened with constantly thinking about it This is self-contradictory. In particular, the only way you can have reliable error handling is if you are forced to think about each possible failure. I assume by "cannot easily be ignored" you mean the way exceptions blow up at runtime? I don't find that an acceptable default for any non-scripting language.
  - macintux 3y ago
    My favorite language is Erlang, which is about as far from Go as it gets from an error handling perspective.

by vira28 3y ago

write on the introduction it says https://build-your-own.org/database/00a_overview https://build-your-own.org/database/00a_overview Or if you see any chapter you can literally see Go code.

macintux 3y ago

You're right, I missed the one place in the introduction where it mentions Golang. Other than the "if err != nil" I wouldn't have recognized the code samples. Go's error handling is a big reason I've never taken a closer look.

bsaul 3y ago
never understood the issue with go error handling. As soon as you start dumping exceptions as a valid error forwarding mechanism ( which seems like a totally acceptable design decision), you end up manually having to check every call you make that can raise an error, on each line. I don't really see any alternative. It also makes you carefully think about how you plan on managing errors in your codebase, which also seems like a very sane thing to enforce.
- ikiris 3y ago
  people who aren't used to actually handling their errors get annoyed at typing return err all the time. They'd prefer an easier way to not bother dealing with them with them without outright ignoring them via _
  - alpaca128 3y ago
    I'd get annoyed too, because I know there are much simpler alternatives. Language design should encourage doing things right by making it more convenient than the shortcuts. In Rust that entire check can be a single "?" symbol. How much syntactic sugar is too much is a matter of preference, but I personally think that properly handling all errors without syntactic sugar turns into an unreadable mess because there's just a lot of things which could go wrong.
    - bsaul 3y ago
      almost 50% of the time i want to add some debugging info to the error before forwarding it one layer above, to provide more context. I think just forwarding all low-level errors is a really bad habit, and go forces you to at least think about this.
      - alpaca128 3y ago
        > I think just forwarding all low-level errors is a really bad habit Why exactly is that a bad habit? In almost all situations where I return an error I already have enough context, I'm just wondering what else I'd add to that. > go forces you to at least think about this Boilerplate code definitely doesn't incentivize thinking.
        deleted 3y ago
        [deleted]
        bsaul 3y ago
        most errors you encounters are with i/o and are stupid "can't read, can't write or can't serialize". In a network environment (which is originally what go was made for) you often need to add tracing information, business-level identifiers or processing information related to your state etc. I'm currently writing a fairly complex api in go, and to be honest this really hasn't bothered me once. Not to say it doesn't exists, but with time i've come very suspicious of people complaints over go. Most of the time those complaints come from people that didn't realize they missed an opportunity to have written a much much more elegant solution to their problem.
        ikiris 3y ago
        or usually just try again with backoff.
    - ikiris 3y ago
      just returning the error isn't handling it.
- jeremyjh 3y ago
  You don't have to trap exceptions separately on every line. You trap a whole block of code and match on the exception type to determine how to handle the problem. It isn't perfect, nothing is, but I prefer systems languages where typical failures cannot easily be ignored and yet you are not burdened with constantly thinking about it.
  - Mawr 3y ago
    > I prefer systems languages where typical failures cannot easily be ignored and yet you are not burdened with constantly thinking about it This is self-contradictory. In particular, the only way you can have reliable error handling is if you are forced to think about each possible failure. I assume by "cannot easily be ignored" you mean the way exceptions blow up at runtime? I don't find that an acceptable default for any non-scripting language.
- macintux 3y ago
  My favorite language is Erlang, which is about as far from Go as it gets from an error handling perspective.