Monadic style or not, the `if err != nil return err` pattern destroys critical information for debugging. `try/catch` gives you a complete stacktrace. That stacktrace is often more valuable than the error message itself.
Funny enough, your code looks like it is inspired by Go, and Go experimented with adding stack traces automatically. Upon inspecting real-world usage, they discovered that nobody ever used the stack traces, and came to learn that good errors already contains everything you'd want to know, making stack traces redundant.
Whether or not you think the made the right choice, it is refreshing that the Go project applies the scientific method before making a choice. The cool part is that replication is the most important piece of the scientific method, so anyone who does think they got it wrong can demonstrate it!
Which is also why it draws so much ire. It speaks the truths developers don't like to admit.
They test with their community and get the biases of their community. Don't pretend it's more than that.
But it doesn't really matter which codebases they used, does it? Replication efforts will reveal anything they got wrong. No need to make guesses.
So you are meaning – with respect to the code – the same as all other software? What, then, is "enterprise" trying to add? It is not like you would write code that makes billions any differently than you would a code that makes a dollar.
Not at all. Fundamentally, you do need understanding in order to criticize. "Criticizing" without understanding is merely whining. If your intent is to whine, you are certainly welcome to until your heart's content, but it will be fruitless. Without you having an understanding – and being able to articulate it – progress cannot be made. This should be obvious.
> A stack trace is ground truth
But a costly truth. Even languages that do pass around stack traces are careful to avoid them except under special circumstances, which is kind of nonsensical from a theoretical point of view. If you find them to be useful, you'd find them useful in all cases. However, it is a necessary tradeoff for the sake of computing efficiency.
With a few small changes to your codebase you can restore the automatic attachment of stack traces like the original experiments had. Stack traces are made available for you to use! But, it remains that the research showed that the typical application didn't ever use it, so it wasn't a sensible default to include given the cost of inclusion. "But, but I wish it were!" doesn't change reality like you seem to think it does.
Understanding comes from all kinds of places. When a child touches a hot stove, they come to understand the consequences. That child doesn't gather 30 participants and record their reactions as they take turns burning their fingers. I'll leave you to extrapolate.
How I come across has no bearing on what is said. This is irrelevant and a pointless distraction.
> Understanding comes from all kinds of places.
If you have an understanding then you've studied it. All that is lacking, then, is the communication of what is understood. Strangely, after several comments, still crickets on the only thing that would add value to the discussion...
And using those utilities to test if an err is of a certain kind now that’s been wrapped a few times
Naked err returns can be a source of pain.