4 ms·

Different strokes for different folks. The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much bet

Different strokes for different folks. The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

gf000 6mo ago
Apples to oranges. Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error case.
- Geezus_42 6mo ago
  > reconstruct the erroneous code path This is only useful to the developers who should be fixing the bug. Us sysadmins need to know the immediate issue to remediate while the client is breathing down our neck. Collect all the stack traces, heap dumps, whatever you want for later review. Just please stop writing them to the main log where we are just trying to identify the immediate issue and have no idea what all the packages those paths point to do. It just creates more text for us to sift through.
  - gf000 6mo ago
    grep "caused by" Here you are.
    - iamcalledrob 6mo ago
      Don't have to grep my go errors :)
      - gf000 6mo ago
        Especially when they forget to properly handle an error case among the litany of if err line noise, and you get erroneous code execution with no record of it!
    - Geezus_42 6mo ago
      Why not just make your errors more readable and not have to use an extra tool?
      - gf000 6mo ago
        Well, just write more readable error messages? How do you make this more readable: ExceptionName: Dev-given message at Class(line number) at Class(line number) caused by AnotherCauseException: Dev-given message at Class(line number) It's only the dev given message that may or may not be of good quality, the exact same way as it is in go. It's a plus that you can't accidentally ignore error cases, and even if a dev was lazy, you still have a pretty good record for where a given error case could originate from.
        Geezus_42 6mo ago
        Again, I am a sysadmin, not a developer. Telling me line numbers in a files written in a language I don't understand is not helpful. I don't care where the error occurred in the code. I care what the error was so I can hopefully fix it, assuming its external and not a bug in the code.

gf000 6mo ago

Apples to oranges. Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error case.

Geezus_42 6mo ago
> reconstruct the erroneous code path This is only useful to the developers who should be fixing the bug. Us sysadmins need to know the immediate issue to remediate while the client is breathing down our neck. Collect all the stack traces, heap dumps, whatever you want for later review. Just please stop writing them to the main log where we are just trying to identify the immediate issue and have no idea what all the packages those paths point to do. It just creates more text for us to sift through.
- gf000 6mo ago
  grep "caused by" Here you are.
  - iamcalledrob 6mo ago
    Don't have to grep my go errors :)
    - gf000 6mo ago
      Especially when they forget to properly handle an error case among the litany of if err line noise, and you get erroneous code execution with no record of it!
  - Geezus_42 6mo ago
    Why not just make your errors more readable and not have to use an extra tool?
    - gf000 6mo ago
      Well, just write more readable error messages? How do you make this more readable: ExceptionName: Dev-given message at Class(line number) at Class(line number) caused by AnotherCauseException: Dev-given message at Class(line number) It's only the dev given message that may or may not be of good quality, the exact same way as it is in go. It's a plus that you can't accidentally ignore error cases, and even if a dev was lazy, you still have a pretty good record for where a given error case could originate from.
      - Geezus_42 6mo ago
        Again, I am a sysadmin, not a developer. Telling me line numbers in a files written in a language I don't understand is not helpful. I don't care where the error occurred in the code. I care what the error was so I can hopefully fix it, assuming its external and not a bug in the code.