preseinger

14 ms·

91.
by preseinger 3y ago
an error should be handled in precisely one way - logged (and control flow continues) - returned (and control flow returns) - managed (and control flow (probably) continues) if you log an error, then you should not return it if you return a
92.
by preseinger 3y ago
nope! go's error handling is actually good! it turns out that treating errors the same as normal values makes programs more reliable lots of people get salty about it, for sure
93.
by preseinger 3y ago
what programs are you writing where error wrapping represents a performance cost that's worth avoiding???
94.
by preseinger 3y ago
stack traces are tools for developers, error messages are tools for users users should not see stack traces
95.
by preseinger 3y ago
go's error handling is not catastrophic, it is very good
96.
by preseinger 3y ago
the parent's point was to compare the set of reserved keywords in the two languages types do not enter the discussion
97.
by preseinger 3y ago
calling a function that can fail means you need to manage that condition inspecting the err value returned by a function call is in fact error handling the point of this design is to keep control flow "on the page" exceptions do n
98.
by preseinger 3y ago
huh? it's exactly the opposite ideally, control flow goes 'down' via func calls, and 'up' via return statements this is the "trivial to see pattern" -- the code as written exceptions subvert those simple r
99.
by preseinger 3y ago
you say "optional", i say "explicit" it's important that i see the `return` keyword in the source code
100.
by preseinger 3y ago
convention prevents it and in the case where returning both is OK, then documentation makes that clear this is not difficult
101.
by preseinger 3y ago
no, it isn't
102.
by preseinger 3y ago
you're saying that guarantees which are not enforced by the compiler are "not as good" as those which are this is not correct but i'm not sure how to convince you of this truth, so (shrug)
103.
by preseinger 3y ago
> Convention is just an educated guess. at some absolute level yes, but at any pragmatic level no, definitely not > No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled
104.
by preseinger 3y ago
> In Go, you are always forced by the language to return a value of type "A or B, including both or neither." The consumer isn't any more in control, it just has to guess whether "both or neither" are possible re
105.
by preseinger 3y ago
? enables chaining, chaining subverts comprehensibility in exactly the ways i'm describing
106.
by preseinger 3y ago
nope error handling (as expressed here) is equivalent in priority to core business logic it absolutely belongs in source, because it is important for developers to see
107.
by preseinger 3y ago
given a function fn that can fail, it will return a result and an error e.g. result, error = fn(...) calling this function should yield to the caller two possibilities, somehow: a success value _or_ a failure error the important th
108.
by preseinger 3y ago
you don't want exception-style "convenience", that's the whole point you want to be able to read code and see a single control flow ? subverts that core requirement
109.
by preseinger 3y ago
if you write a line of code that can fail, then you should deal with the possibility of that line failing there, directly, in-line _how_ you deal with that failure is a separate question but it's critical that every fallible expression
110.
by preseinger 3y ago
fmt.Printf failures are un-actionable, so there's no reason to handle them
111.
by preseinger 3y ago
the idea that error handling "pollutes" code is a misunderstanding which go addresses the "sad path" of error handling is equally as important as the "happy path"
112.
by preseinger 3y ago
please don't do this it obfuscates the control flow, specifically the value that is actually returned early returns on errors are good, not bad edit you want func foo() error { x, err := bar() if err != nil {
113.
by preseinger 3y ago
you define Transition over T comparable, but there is no guarantee that comparable implements json.Marshaler, so FSM's MarshalJSON and UnmarshalJSON don't really work
114.
by preseinger 3y ago
"raw sql" is table stakes, core competency for every software engineer ORMs 100% always do it worse
115.
by preseinger 3y ago
it doesn't matter what the data represents, what matters is the structure of that data, and specifically (for SQL) that it is relational, rather than key-value or document-oriented or whatever many business domains are well-modeled by
116.
by preseinger 3y ago
querying relational data with set theory is pretty different to expressing imperative programs in a programming language sql is not a programming language in the traditional sense, it's a mistake to try to think of it in those terms, o
117.
by preseinger 3y ago
what do you think would happen if there was a comment about go on the internet that you somehow didn't see, and to which you weren't able to reply with a sarcastic and sneering dismissal? probably some serious kind of disaster, ri
118.
by preseinger 3y ago
func (fsm *FSM[T]) Transition(...) { ... fsm.Transitions[time.Now()] = Transition[T]{ FromState: *fsm.CurrentState, ToState: targetState, Timestamp: &tn, Metadata: metadata, } d
119.
by preseinger 3y ago
this is 100% not what a distributed monolith is a distributed monolith is an antipattern that's common to badly executed microservices -- it's essentially an epithet, in no sense a design goal what's being described here is a
120.
by preseinger 3y ago
it is not, "edge" is just a marketing claim here

More ›