It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed.
Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.”
The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the times when it’s applicable is a huge red flag and is exactly why people complain about Go.
It feels like you’re constantly fighting the language: having to add error handling boilerplate everywhere and having to pass contexts everywhere (more boilerplate). This is the intersection of those two annoyances so it feels especially annoying (particularly given the nuances/footguns the author describes).
They say the point is that Go forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it. After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
I hope someday they make another attempt at a Go 2.0.
There are two things I think you could have as implict in Go - error values, and contexts.
Just pass along two hidden variables for both in parameters and returns, and would anything really change that the compiler wouldn't be able to follow?
i.e. most functions return errors, so there should always be an implicit error return possible even if I don't use it. Let the compiler figure out if it needs to generate code for it.
And same story for contexts: why shouldn't a Go program be a giant context tree? If a branch genuinely doesn't ever use it, the compiler should be able to just knock the code out.
What's the difference between an implicit error and exceptions? Being explicit about errors is good. Go's syntactical implementation, coupled with its unexpressive type system, is the problem.
I will freely go on the record as saying that there's nothing wrong with exceptions for this exact reason: errors are so common that a function being "pure" is the exception, and that errors-as-value handling invariable turns into an endless chain of something like "if err; return (nil/zero, err)" in every language which tries it.
The same would apply to anytime you have Result types - ultimately its still just syntactic sugar over "if err then...".
What's far more common in real programs is that an error can occur somewhere where you do not have enough context to handle or resolve it, or you're unaware it can happen. In which case the concept of exceptions is much more valid: "if <bad thing here> what do I want to do?" usually only has a couple of places you care about the answer (i.e. "bad thing happened during business process, so start unwinding that process" and many more where the answer is either "crash" or "log it and move on to the next item".
Exceptions can be bad if done the wrong way. But the solution isn’t to not deal with it and put it on the programmer. That’s laziness.
The problems are that the signature of functions doesn’t say anything about what values it might throw, and that sometimes the control flow is obscured — an innocuous call throws.
Sure but that also feels like a compiler problem. The compiler knows everywhere my function can go. So rather then having it just throw an exception - i.e. arbitrary data - on the stack, surely what's really happening is I'm creating a big union of "result | error[type,type,type,type]" which only gets culled when I add my "exception" handling.
My argument here would be, that all of this though doesn't need to be seen unless its relevant - it seems reasonable that the programmer should be able to write code for the happy path, implicitly understanding there's an error path they should be aware of because errors always happen (I mean, you can straight up run out of memory almost anywhere, for example).
I agree go’s error handling feels a bit clunky, though I prefer the local error handling and passing up the chain (if it were a bit more ergonomic) to exceptions, which IMO have a lot of other problems.
The main problems seem to me to be boilerplate and error types being so simplistic (interface just has a method returning a string). Boilerplate definitely seems solvable and a proper error interface too. I tend to use my own error type where I want more info (as in networking errors) but wish Go had an interface with at least error codes that everyone used and was used in the stdlib.
My rule of thumb on annotation is default to no, and add it at the top level. You’ll soon realise if you need more.
It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.
Well two things to me feel clunky, first is less serious but leads to lots of verbosity:
1. if err != nil is verbose and distracting and happens a lot. I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error:
// ? Returns error if non-nil, otherwise continue
data, err := os.ReadFile(path) ?
// Current situation
data, err := os.ReadFile(path)
if err != nil {
return x,y,z,err
}
The second is a problem of culture more than anything but the stdlib is to blame:
2. The errors pkg and error interface has very basic string-based errors. This is used throughout the stdlib and of course in a lot of go code so we are forced to interact with it. It also encourages people to string match on errors to identify them etc etc. Yes you can use your own error types and error interfaces but this then creates interop problems and inevitably many pkgs you use return the error interface. I use my own error types, but still have to use error a lot due to stdlib etc. The wrapping they added and the annotation they encourage is also pretty horrible IMO, returning a bunch of concatted strings.
So these are not things that end users of the language can fix. Surely we can do better than this for error handling?
> if err != nil is verbose and distracting and happens a lot.
if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
If there is something about errors that happening a lot then that still questions your design. Keep trying new ideas until it isn't happening a lot.
> Surely we can do better than this for error handling?
Surely we can do better for handling of all types? And in theory we can. In practice, it is like the story of generics in Go: Nobody smart enough to figure out a good solution wants to put in the work. Google eventually found a domain expert in generics to bring in as a contractor to come up with a design, but, even assuming Google is still willing to invest a lot of money in the new budget-tightening tech landscape, it is not clear who that person is in this case.
Ian Lance Taylor, as you mention, tried quite hard — with work spanning over many years — in both in both cases to find a solution, which we should commend him for, but that type of design isn't really his primary wheelhouse.
> if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
In practice though, there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times in the same function. Whether the issue is "about errors" specifically doesn't really change the relatively common view that it's an annoying pattern. It's not surprising that some people might be more interested in fixing the practical annoyance that they deal with every day even if it's not a solution to the general problem that no one has made progress on for over a decade.
> there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times
In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
> it's an annoying pattern.
But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
> It's not surprising that some people might be more interested in fixing
If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be?
Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
> In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
I don't agree with the premise that a frustrating pattern has to comprise a large percentage of the instances of the general syntax for people to want to change it. I can tell you do, but I don't think this is something that people will universally agree with, and I'd argue that telling people "you can't have the opinion you have because it doesn't make sense to me" isn't a very effective or useful statement.
> But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
Empirically, people don't seem to think they have better options, or else they'd be using them. If you try to solve someone's problem by giving them a different tool, and they still say they have the problem even with that, you're probably not going to convince them by telling them "you're doing it bad".
> If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be?
> Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
I'd argue there have been plenty of solutions for the specific problem that's being discussed here proposed that are rejected for not being general solutions to the problem that you're describing. My point is that there's a decent number of people who aren't satisfied with this, and would prefer that this is something solved in the specific case rather than the general for the exact reason you pointed out: it doesn't seem like anyone is willing or able to solve it in the general case.
My point is that I think a lot of people want a solution to a specific problem, and you don't want that problem solved unless it solves the general problem that the problem is a specific case of. There's nothing wrong with that, but your objections are mostly phrased as claiming that they don't actually have the problem they have, and I think that's kind of odd. It's totally fair to hold the opinion that solving the specific problem would not be a good idea, but telling people that they don't care about what they care about is just needlessly provocative.
I like nice things. You've identified a clear pain point that I agree with. If something can be better, why not make it better? "I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
> Empirically, people don't seem to think they have better options, or else they'd be using them.
I have read many Go codebases that do a great job with errors, without all the frustration you speak of. I've also read codebases where the authors crated great messes and I know exactly what you're talking about. That isn't saying Go couldn't improve in any way, but it does say that design matters. If your design sucks, fix it. Don't design your code as if you are writing in some other language.
> My point is that there's a decent number of people who aren't satisfied with this
Including the Go team. Hence why Ian Lance Taylor (who isn't on the core team anymore, granted, but was at the time) went as far as to create a build of Go that exhibited the change he wanted to see. But, once it was tried, we learned it wasn't right.
Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
> I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
This is exactly what I mean by needlessly provocative. You're almost directly saying that people who happen to care more about one specific case than you do are stupid or naive rather than having a different technical opinion than you. If you genuinely think that people who disagree with you are stupid or naive, then I don't understand why you'd bother trying to engage with them. If you think they aren't, but their ideas are, I don't think you're going to be effective at trying to educate them by talking down to them like this.
> Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Whether a design "actually works" is dependent on what the actual thing it's trying to solve is, since a design that works for one problem might not solve another. This is still circular; you're defining the problem to be larger than what the proposals were trying to solve, so of course they didn't solve what you're looking for. You're obviously happier with nothing changing if it doesn't solve the general problem, which is a perfectly valid opinion, but you're talking in absolute terms as if anyone who disagrees with you is objectively wrong rather than having a subjectively different view on what the right tradeoff is.
> Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally. If nobody is capable of solving a large problem, some people will want to solve a small one instead. The issue isn't that I can't personally see beyond the end of my nose, but that unless someone comes up with the solution, it's impossible to tell the difference between whether it's a few hundred yards outside my field of view or light-years away in another galaxy we'll never reach. I'd argue that there should be some threshold where after enough time, it's worth it to stop holding out for a perfect solution and accept one that only solves an immediate obvious problem, and further that we've reached that threshold. You can disagree with that, but condescending to people who don't have the same view as you isn't going to convince anyone, so I don't understand what the point of it is other than if you're just trying to feel smugly superior.
> This is exactly what I mean by needlessly provocative.
This doesn't make sense. You might be mistakenly anthropomorphizing HN?
> so of course they didn't solve what you're looking for.
What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
> Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally.
The Go project is looking for a subset solution. Nobody knows, even within that subset, of how to make it work.
Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
No matter how much you hope and pray, things cannot magically appear. Someone has to do it.
> This doesn't make sense. You might be mistakenly anthropomorphizing HN?
You're a human talking to other humans. Yes, you're online, but there are still a range of ways you can phrase things, some of which are more polite than others. I don't understand what doesn't make sense about it, although as always you're free to disagree.
> What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
Go is not a monolithic community, and for obvious reasons the people making decisions are a much smaller group than the community as a whole. Not everyone in the community will agree with every decision, and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged. You're stating it as fact that this isn't the case, and obviously I'm not going to convince you otherwise, but it's clear you don't have any desire to provide any more context because you think your claim is self-evident.
> Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers and every proposal will somehow be either something that will strictly fit what with every single one of them wants or be bad for all of them (regardless of what they say they want). Alternately, maybe there's nuance where different people have competing technical views on what would make sense or disagreeing views on subjective matters, and the lack of a solution having been adopted doesn't mean that it's impossible for someone to think that anything that's been discussed would be a good idea without being objectively wrong. Given that you'd rather refer to any other viewpoint as akin to magical hopes and prayers, you obviously don't think that it's possible anyone else could have something reasonable to say on the issue if it disagrees with your opinions, so I guess we've both been wasting our time here.
Okay. Let's put that to the test. Describe my human features. What do I look like, sound like?
> and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged.
Fair enough. What do they say to the specific criticism that brought rejection?
> Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers
They satisfy 100% of Go programmers, but not all programmers. Those who aren't satisfied are already using another language or have forked Go to make it what they actually need. Even Google uses their own fork, funnily enough. If something doesn't work for you, you can't sensibly continue to use it.
Yes I guess I do annotation in two places - initial error deep in libraries is annotated, this is passed back up to the initial handlers who log and respond and decide what to show users. Obviously that’s just a rule of thumb and doesn’t always apply.
Depends if it can be handled lower (with a retry or default data for example), if it can be it won’t be passed all the way up.
Generally though I haven’t personally found it useful to always annotate at every point in the call chain. So my default is not to annotate and if err return err.
What I like about errors instead of exceptions is they are boring and predictable and in the call signature so I wouldn’t want to lose that.
I actually like the explicit error and context value stuff in Go, though I recognise I'm in the minority.
The main reason is more to do with maintaining Go code than writing it: I find it very helpful when reading Go code and debugging it, to see actual containers of values get passed around.
Also, whenever I write a bit of boilerplate to return an error up, that is a reminder to consider the failure paths of that call.
Finally, I like the style of having a very clear control flow. I prefer to see the state getting passed in and returned back, rather than "hidden away".
I know that there are other approaches to having clear error values, like an encapsulated return value, and I like that approach as well - but there is also virtue in having simple values. And yes there are definitely footguns due to historical design choices, but the Go language server is pretty good at flagging those, and it is the stubborn commitment to maintaining the major API V1 that makes the language server actually reliable to use (my experience working with Elixir's language server has been quite different, for example).
> It feels like you’re constantly fighting the language
I disagree. I feel like I constantly understand precisely what the language is and is not going to do. This is more valuable to me than languages with 100 sigils that all invoke some kind of "magic path" through my code.
> forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it
How do you universally handle an inventory error? The _path_ to and from the error is more important than the error or it's handling clauses.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
Isn't the point of the above that no matter which you choose the code is mostly the same? How much of an impact is this to refactor when you change your mind? For me it's almost zero. That right there is why I use go.
It was a great piece and I learned a lot, thanks for writing it. I hope you didn’t think that it was you I was disappointed with rather than the language designers :)
It’s ironic how context cancellation has the opposite problem as error handling.
With errors they force you to handle every error explicitly which results in people adding unnecessary contextual information: it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace.
With context cancellation OTOH you have to go out of your way to add contextual info at all, and even then it’s not as simple as just using the new machinery because as your piece demonstrates it doesn’t all work well together so you have to go even further out of your way and roll your own timeout-based cancellation. Absurd.
No worries. Your intent was clear. I don't mind the boilerplates if they were footgun free. Context requires you write a bunch of boilerplate where it's still really easy to make mistakes.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
When writing your tests:
1. Ensure all error cases are identifiable to the caller — i.e. using errors.Is/errors.AsType
2. Ensure that you are not leaking the errors from another package — you might change the underlying package later, so you don't want someone to come to depend on it
As long as those are satisfied, it doesn't matter how it is implemented.
Your example shows an ideal case w/o repetition. If every layer just wraps error without inspecting, then there will be duplication in the error string.
I have never seen that. I have shipped multiple dozens of services at half a dozen companies. Big code bases. Large teams. Large volumes of calls and data. Complicated distributed systems.
I am unable to imagine a case where an error string repeated itself. On a loop, an error could repeat, but those show as a numerical count value or as separate logs.
Not in my experience. Usually your call chain has forks. Usually the DoThing function will internally do 3 things and any one of those three things failed and you need a different error message to disambiguate. And four methods call DoThing. The 12 error paths need 12 uniquely rendered error messages. Some people say "that is just stack traces," and they are close. It is a concise stack trace with the exact context that focuses on your code under control.
If you have both the start of the call chain and the end of the call chain mapped you will get a different error response almost every time and it is usually more than enough, so say your chain is:
Do1:...Do10, which then DoX,DoY,DoZ and one of those last 3 failed.
Do you really need Do1 to Do10 to be annotated to know that DoY failed when called from Do1? I find:
Do1:DoZ failed for reason bar
Just as useful and a lot shorter than:
Do1: failed:Do2:failed...Do9 failed:Do10:failed:DoZ failed for reason bar
It is effectively a stack trace stored in strings, why not just embed a proper stack trace to all your errors if that is what you want?
Your concern with having a stack trace of calls seems a hypothetical concern to me but perhaps we just work on different kinds of software. I think though you should allow that for some people annotating each error just isn't that useful, even if it is useful for you.
I have a single wrap function that does this for all errors. The top level handler only prints the first two, but can print all if needed.
I have never had difficulty quickly finding the error given only the top two stack sites.
Any complaint about go boilerplate is flawed. The purpose and value is not in reducing code written, it is to make code easier to read and it achieves this goal better than any other language.
I close my nose and always wrap errors with a sentinel error for public functions/methods so that callers can check with `errors.Is`. And you can always identify the place in the call-stack where the error occurred.
I need to start getting used to context with cancel cause - muscle memory hasn't changed yet.
Go is seen as too boiler plate-ish, and no one likes that. But one of the biggest Go's biggest assets is its simplicity. And it might not be possible to have both simplicity and low boiler plate.
I quite enjoy C# and F# and while they are low boiler plate, you can really learn them in a week or two the way you can learn Go.
And even you don't know anything about Go, you can literally jump into the code base and understand and follow the flow with ease - which quite amazes me.
So unfortunately, every language has trade offs and Go is not an exception.
I can't say I enjoy Go as a language but I find it very, very useful.
And since many people are using LLMs for coding these days, the boiler plate is not as much an issue since it be automated away. And I rather read code generated in Go than some C++ cryptic code.
Not at all, information is out there in case you want to properly educate yourself on what dynamic compilers are, and what AOT options exist since the 2000's.
ZIO in Scala tracks this sort of thing except you don't have to remember to pass around or select on the ctx (it's just part of the fibre/"goroutine"); if it's cancelled, the fibre and its children just stops the next time it yields (so e.g. if it "selects" on anything or does any kind of IO).
Haskell is the king of cancellation. Using asynchronous exceptions, you can cancel anything, anytime, with user
-defined exception types so you know what the cancellation reason is.
Example:
maybeVal <— timeout 1000000 myFunction
Some people think that async exceptions are a pain because you nerd to be prepared that your code can be interrupted any time, but I think it's absolutely worth it because in all the other languages I encounter progress bars that keep running when I click the cancel button, or CLI programs that don't react to CTRL+C.
In Haskell, cancellability is the default and carries no syntax overhead.
This is one of the reasons why I think Haskell is currently the best language for writing IO programs.
Python async tasks can be cancelled. But, I don't think you can attach must context to the cancel (I think you can pass a text message), so it would seem the argument of what go suffered from would apply.
(I also think there's some wonkiness with and barriers to understanding Python's implementation that I don't think plagues Go to quite the same extent.)
All mainstream languages have it in one or more forms (either direct task I/O cancellation, or cancellation tokens or I/O polling that can include synthetic events) since otherwise several I/O patterns are impossible
I think this post needs better examples to show case the issue, because right now the issue is not clear. Ideally you would need an example that uses the context.Cause function, see below
The contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.
Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.
Not only that, isn't this a "lie"? You're cancelling the context explicitly, but that's not necessary is it? Because at the moment the above call fails, the called-into functions might not have cancelled the context. There might be cleanup running later on which will then refuse to run on this eagerly cancelled context. There is no need to cancel this eagerly.
Perhaps I'm not seeing the problem being solved, but bog-standard `return err` with "lazy" context cancellation (in a top-level `defer cancel()`), or eager (in a leaf I/O goroutine) seems to carry similar functionality. Stacking both with ~identical information seems redundant.
Golang returning tuples but not having pattern matching is something I'll never get. I really feel it's a too dumbed down version of erlang/elixir, especially with this context passing business
It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed.
Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.”
The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the times when it’s applicable is a huge red flag and is exactly why people complain about Go.
It feels like you’re constantly fighting the language: having to add error handling boilerplate everywhere and having to pass contexts everywhere (more boilerplate). This is the intersection of those two annoyances so it feels especially annoying (particularly given the nuances/footguns the author describes).
They say the point is that Go forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it. After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
I hope someday they make another attempt at a Go 2.0.
There are two things I think you could have as implict in Go - error values, and contexts.
Just pass along two hidden variables for both in parameters and returns, and would anything really change that the compiler wouldn't be able to follow?
i.e. most functions return errors, so there should always be an implicit error return possible even if I don't use it. Let the compiler figure out if it needs to generate code for it.
And same story for contexts: why shouldn't a Go program be a giant context tree? If a branch genuinely doesn't ever use it, the compiler should be able to just knock the code out.
What's the difference between an implicit error and exceptions? Being explicit about errors is good. Go's syntactical implementation, coupled with its unexpressive type system, is the problem.
I will freely go on the record as saying that there's nothing wrong with exceptions for this exact reason: errors are so common that a function being "pure" is the exception, and that errors-as-value handling invariable turns into an endless chain of something like "if err; return (nil/zero, err)" in every language which tries it.
The same would apply to anytime you have Result types - ultimately its still just syntactic sugar over "if err then...".
What's far more common in real programs is that an error can occur somewhere where you do not have enough context to handle or resolve it, or you're unaware it can happen. In which case the concept of exceptions is much more valid: "if <bad thing here> what do I want to do?" usually only has a couple of places you care about the answer (i.e. "bad thing happened during business process, so start unwinding that process" and many more where the answer is either "crash" or "log it and move on to the next item".
Exceptions can be bad if done the wrong way. But the solution isn’t to not deal with it and put it on the programmer. That’s laziness.
The problems are that the signature of functions doesn’t say anything about what values it might throw, and that sometimes the control flow is obscured — an innocuous call throws.
Both of these are solvable.
Sure but that also feels like a compiler problem. The compiler knows everywhere my function can go. So rather then having it just throw an exception - i.e. arbitrary data - on the stack, surely what's really happening is I'm creating a big union of "result | error[type,type,type,type]" which only gets culled when I add my "exception" handling.
My argument here would be, that all of this though doesn't need to be seen unless its relevant - it seems reasonable that the programmer should be able to write code for the happy path, implicitly understanding there's an error path they should be aware of because errors always happen (I mean, you can straight up run out of memory almost anywhere, for example).
I agree, and I think that the simplicity mantra of the early go team caused them to not deal with solvable problems when they had the chance.
They would rather not solve it, thinking that the "programmers will deal with it".
Now they claim it’s too late.
I agree go’s error handling feels a bit clunky, though I prefer the local error handling and passing up the chain (if it were a bit more ergonomic) to exceptions, which IMO have a lot of other problems.
The main problems seem to me to be boilerplate and error types being so simplistic (interface just has a method returning a string). Boilerplate definitely seems solvable and a proper error interface too. I tend to use my own error type where I want more info (as in networking errors) but wish Go had an interface with at least error codes that everyone used and was used in the stdlib.
My rule of thumb on annotation is default to no, and add it at the top level. You’ll soon realise if you need more.
How would you fix it if given the chance?
> I agree go’s error handling feels a bit clunky
It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.
Well two things to me feel clunky, first is less serious but leads to lots of verbosity:
1. if err != nil is verbose and distracting and happens a lot. I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error:
// ? Returns error if non-nil, otherwise continue
data, err := os.ReadFile(path) ?
// Current situation
data, err := os.ReadFile(path)
if err != nil {
}The second is a problem of culture more than anything but the stdlib is to blame:
2. The errors pkg and error interface has very basic string-based errors. This is used throughout the stdlib and of course in a lot of go code so we are forced to interact with it. It also encourages people to string match on errors to identify them etc etc. Yes you can use your own error types and error interfaces but this then creates interop problems and inevitably many pkgs you use return the error interface. I use my own error types, but still have to use error a lot due to stdlib etc. The wrapping they added and the annotation they encourage is also pretty horrible IMO, returning a bunch of concatted strings.
So these are not things that end users of the language can fix. Surely we can do better than this for error handling?
> if err != nil is verbose and distracting and happens a lot.
if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
If there is something about errors that happening a lot then that still questions your design. Keep trying new ideas until it isn't happening a lot.
> Surely we can do better than this for error handling?
Surely we can do better for handling of all types? And in theory we can. In practice, it is like the story of generics in Go: Nobody smart enough to figure out a good solution wants to put in the work. Google eventually found a domain expert in generics to bring in as a contractor to come up with a design, but, even assuming Google is still willing to invest a lot of money in the new budget-tightening tech landscape, it is not clear who that person is in this case.
Ian Lance Taylor, as you mention, tried quite hard — with work spanning over many years — in both in both cases to find a solution, which we should commend him for, but that type of design isn't really his primary wheelhouse.
> if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
In practice though, there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times in the same function. Whether the issue is "about errors" specifically doesn't really change the relatively common view that it's an annoying pattern. It's not surprising that some people might be more interested in fixing the practical annoyance that they deal with every day even if it's not a solution to the general problem that no one has made progress on for over a decade.
> there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times
In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
> it's an annoying pattern.
But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
> It's not surprising that some people might be more interested in fixing
If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be?
Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
> In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
I don't agree with the premise that a frustrating pattern has to comprise a large percentage of the instances of the general syntax for people to want to change it. I can tell you do, but I don't think this is something that people will universally agree with, and I'd argue that telling people "you can't have the opinion you have because it doesn't make sense to me" isn't a very effective or useful statement.
> But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
Empirically, people don't seem to think they have better options, or else they'd be using them. If you try to solve someone's problem by giving them a different tool, and they still say they have the problem even with that, you're probably not going to convince them by telling them "you're doing it bad".
> If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be? > Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
I'd argue there have been plenty of solutions for the specific problem that's being discussed here proposed that are rejected for not being general solutions to the problem that you're describing. My point is that there's a decent number of people who aren't satisfied with this, and would prefer that this is something solved in the specific case rather than the general for the exact reason you pointed out: it doesn't seem like anyone is willing or able to solve it in the general case.
My point is that I think a lot of people want a solution to a specific problem, and you don't want that problem solved unless it solves the general problem that the problem is a specific case of. There's nothing wrong with that, but your objections are mostly phrased as claiming that they don't actually have the problem they have, and I think that's kind of odd. It's totally fair to hold the opinion that solving the specific problem would not be a good idea, but telling people that they don't care about what they care about is just needlessly provocative.
> I can tell you do
I like nice things. You've identified a clear pain point that I agree with. If something can be better, why not make it better? "I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
> Empirically, people don't seem to think they have better options, or else they'd be using them.
I have read many Go codebases that do a great job with errors, without all the frustration you speak of. I've also read codebases where the authors crated great messes and I know exactly what you're talking about. That isn't saying Go couldn't improve in any way, but it does say that design matters. If your design sucks, fix it. Don't design your code as if you are writing in some other language.
> My point is that there's a decent number of people who aren't satisfied with this
Including the Go team. Hence why Ian Lance Taylor (who isn't on the core team anymore, granted, but was at the time) went as far as to create a build of Go that exhibited the change he wanted to see. But, once it was tried, we learned it wasn't right.
Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
> I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
This is exactly what I mean by needlessly provocative. You're almost directly saying that people who happen to care more about one specific case than you do are stupid or naive rather than having a different technical opinion than you. If you genuinely think that people who disagree with you are stupid or naive, then I don't understand why you'd bother trying to engage with them. If you think they aren't, but their ideas are, I don't think you're going to be effective at trying to educate them by talking down to them like this.
> Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Whether a design "actually works" is dependent on what the actual thing it's trying to solve is, since a design that works for one problem might not solve another. This is still circular; you're defining the problem to be larger than what the proposals were trying to solve, so of course they didn't solve what you're looking for. You're obviously happier with nothing changing if it doesn't solve the general problem, which is a perfectly valid opinion, but you're talking in absolute terms as if anyone who disagrees with you is objectively wrong rather than having a subjectively different view on what the right tradeoff is.
> Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally. If nobody is capable of solving a large problem, some people will want to solve a small one instead. The issue isn't that I can't personally see beyond the end of my nose, but that unless someone comes up with the solution, it's impossible to tell the difference between whether it's a few hundred yards outside my field of view or light-years away in another galaxy we'll never reach. I'd argue that there should be some threshold where after enough time, it's worth it to stop holding out for a perfect solution and accept one that only solves an immediate obvious problem, and further that we've reached that threshold. You can disagree with that, but condescending to people who don't have the same view as you isn't going to convince anyone, so I don't understand what the point of it is other than if you're just trying to feel smugly superior.
> This is exactly what I mean by needlessly provocative.
This doesn't make sense. You might be mistakenly anthropomorphizing HN?
> so of course they didn't solve what you're looking for.
What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
> Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally.
The Go project is looking for a subset solution. Nobody knows, even within that subset, of how to make it work.
Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
No matter how much you hope and pray, things cannot magically appear. Someone has to do it.
> This doesn't make sense. You might be mistakenly anthropomorphizing HN?
You're a human talking to other humans. Yes, you're online, but there are still a range of ways you can phrase things, some of which are more polite than others. I don't understand what doesn't make sense about it, although as always you're free to disagree.
> What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
Go is not a monolithic community, and for obvious reasons the people making decisions are a much smaller group than the community as a whole. Not everyone in the community will agree with every decision, and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged. You're stating it as fact that this isn't the case, and obviously I'm not going to convince you otherwise, but it's clear you don't have any desire to provide any more context because you think your claim is self-evident.
> Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers and every proposal will somehow be either something that will strictly fit what with every single one of them wants or be bad for all of them (regardless of what they say they want). Alternately, maybe there's nuance where different people have competing technical views on what would make sense or disagreeing views on subjective matters, and the lack of a solution having been adopted doesn't mean that it's impossible for someone to think that anything that's been discussed would be a good idea without being objectively wrong. Given that you'd rather refer to any other viewpoint as akin to magical hopes and prayers, you obviously don't think that it's possible anyone else could have something reasonable to say on the issue if it disagrees with your opinions, so I guess we've both been wasting our time here.
> You're a human talking to other humans.
Okay. Let's put that to the test. Describe my human features. What do I look like, sound like?
> and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged.
Fair enough. What do they say to the specific criticism that brought rejection?
> Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers
They satisfy 100% of Go programmers, but not all programmers. Those who aren't satisfied are already using another language or have forked Go to make it what they actually need. Even Google uses their own fork, funnily enough. If something doesn't work for you, you can't sensibly continue to use it.
In an HTTP server, top level means the handlers, is that so?
Yes I guess I do annotation in two places - initial error deep in libraries is annotated, this is passed back up to the initial handlers who log and respond and decide what to show users. Obviously that’s just a rule of thumb and doesn’t always apply.
Depends if it can be handled lower (with a retry or default data for example), if it can be it won’t be passed all the way up.
Generally though I haven’t personally found it useful to always annotate at every point in the call chain. So my default is not to annotate and if err return err.
What I like about errors instead of exceptions is they are boring and predictable and in the call signature so I wouldn’t want to lose that.
I actually like the explicit error and context value stuff in Go, though I recognise I'm in the minority.
The main reason is more to do with maintaining Go code than writing it: I find it very helpful when reading Go code and debugging it, to see actual containers of values get passed around.
Also, whenever I write a bit of boilerplate to return an error up, that is a reminder to consider the failure paths of that call.
Finally, I like the style of having a very clear control flow. I prefer to see the state getting passed in and returned back, rather than "hidden away".
I know that there are other approaches to having clear error values, like an encapsulated return value, and I like that approach as well - but there is also virtue in having simple values. And yes there are definitely footguns due to historical design choices, but the Go language server is pretty good at flagging those, and it is the stubborn commitment to maintaining the major API V1 that makes the language server actually reliable to use (my experience working with Elixir's language server has been quite different, for example).
> It feels like you’re constantly fighting the language
I disagree. I feel like I constantly understand precisely what the language is and is not going to do. This is more valuable to me than languages with 100 sigils that all invoke some kind of "magic path" through my code.
> forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it
How do you universally handle an inventory error? The _path_ to and from the error is more important than the error or it's handling clauses.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
Isn't the point of the above that no matter which you choose the code is mostly the same? How much of an impact is this to refactor when you change your mind? For me it's almost zero. That right there is why I use go.
Author here. I absolutely hated writing this piece after shooting myself in the foot a thousand times.
Go's context ergonomics is kinda terrible and currently there's no way around it.
It was a great piece and I learned a lot, thanks for writing it. I hope you didn’t think that it was you I was disappointed with rather than the language designers :)
It’s ironic how context cancellation has the opposite problem as error handling.
With errors they force you to handle every error explicitly which results in people adding unnecessary contextual information: it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace.
With context cancellation OTOH you have to go out of your way to add contextual info at all, and even then it’s not as simple as just using the new machinery because as your piece demonstrates it doesn’t all work well together so you have to go even further out of your way and roll your own timeout-based cancellation. Absurd.
No worries. Your intent was clear. I don't mind the boilerplates if they were footgun free. Context requires you write a bunch of boilerplate where it's still really easy to make mistakes.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
When writing your tests:
1. Ensure all error cases are identifiable to the caller — i.e. using errors.Is/errors.AsType
2. Ensure that you are not leaking the errors from another package — you might change the underlying package later, so you don't want someone to come to depend on it
As long as those are satisfied, it doesn't matter how it is implemented.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
The rule of thumb is to wrap always.
Then it results in an absurd amount of duplication. I regularly encounter error strings like:
error:something happened:error:something happened
Yes, and that is desired.
Error: failed processing order: account history load failure: getUser error: context deadline exeeded
Your example shows an ideal case w/o repetition. If every layer just wraps error without inspecting, then there will be duplication in the error string.
I have never seen that. I have shipped multiple dozens of services at half a dozen companies. Big code bases. Large teams. Large volumes of calls and data. Complicated distributed systems.
I am unable to imagine a case where an error string repeated itself. On a loop, an error could repeat, but those show as a numerical count value or as separate logs.
This feels like manually written stacktraces
I’d find Error: failed processing order: context deadline exceeded just as useful and more concise.
Typically there is only one possible code path if you can identify both ends.
Not in my experience. Usually your call chain has forks. Usually the DoThing function will internally do 3 things and any one of those three things failed and you need a different error message to disambiguate. And four methods call DoThing. The 12 error paths need 12 uniquely rendered error messages. Some people say "that is just stack traces," and they are close. It is a concise stack trace with the exact context that focuses on your code under control.
If you have both the start of the call chain and the end of the call chain mapped you will get a different error response almost every time and it is usually more than enough, so say your chain is:
Do1:...Do10, which then DoX,DoY,DoZ and one of those last 3 failed.
Do you really need Do1 to Do10 to be annotated to know that DoY failed when called from Do1? I find:
Do1:DoZ failed for reason bar
Just as useful and a lot shorter than: Do1: failed:Do2:failed...Do9 failed:Do10:failed:DoZ failed for reason bar
It is effectively a stack trace stored in strings, why not just embed a proper stack trace to all your errors if that is what you want?
Your concern with having a stack trace of calls seems a hypothetical concern to me but perhaps we just work on different kinds of software. I think though you should allow that for some people annotating each error just isn't that useful, even if it is useful for you.
After a decade of writing go, I always wrap with the function name and no other content. For instance:
do c: edit b: create a: something happened
For functions called doC, editB, createA.
It’s like a stack trace and super easy to find the codepath something took.
I have a single wrap function that does this for all errors. The top level handler only prints the first two, but can print all if needed.
I have never had difficulty quickly finding the error given only the top two stack sites.
Any complaint about go boilerplate is flawed. The purpose and value is not in reducing code written, it is to make code easier to read and it achieves this goal better than any other language.
This value is compounding with coding agents.
I close my nose and always wrap errors with a sentinel error for public functions/methods so that callers can check with `errors.Is`. And you can always identify the place in the call-stack where the error occurred.
I need to start getting used to context with cancel cause - muscle memory hasn't changed yet.
Go is seen as too boiler plate-ish, and no one likes that. But one of the biggest Go's biggest assets is its simplicity. And it might not be possible to have both simplicity and low boiler plate.
I quite enjoy C# and F# and while they are low boiler plate, you can really learn them in a week or two the way you can learn Go.
And even you don't know anything about Go, you can literally jump into the code base and understand and follow the flow with ease - which quite amazes me.
So unfortunately, every language has trade offs and Go is not an exception.
I can't say I enjoy Go as a language but I find it very, very useful.
And since many people are using LLMs for coding these days, the boiler plate is not as much an issue since it be automated away. And I rather read code generated in Go than some C++ cryptic code.
Go 2.0 already exists, Java, D, C#, Swift, F#, OCaml,....
The community is special and now with the original authors mostly gone, and AI into the mix, I don't see it ever happen.
We will get ridiculous Go 1.xyzabc version numbers.
Go compiles to machine-native language.
Java, C# and so on are scripting languages that compile to bytecode that's then run by a painfully slow interpreter.
Not at all, information is out there in case you want to properly educate yourself on what dynamic compilers are, and what AOT options exist since the 2000's.
Context cancellation (and it's propagation) is one of the best features in Go.
Is there any equivalent in major popular languages like Python, Java, or JS of this?
ZIO in Scala tracks this sort of thing except you don't have to remember to pass around or select on the ctx (it's just part of the fibre/"goroutine"); if it's cancelled, the fibre and its children just stops the next time it yields (so e.g. if it "selects" on anything or does any kind of IO).
Haskell is the king of cancellation. Using asynchronous exceptions, you can cancel anything, anytime, with user -defined exception types so you know what the cancellation reason is.
Example:
Some people think that async exceptions are a pain because you nerd to be prepared that your code can be interrupted any time, but I think it's absolutely worth it because in all the other languages I encounter progress bars that keep running when I click the cancel button, or CLI programs that don't react to CTRL+C.In Haskell, cancellability is the default and carries no syntax overhead.
This is one of the reasons why I think Haskell is currently the best language for writing IO programs.
How do it work inside `myFunction1` which is invoked by `myFunction`? Does `myFunction1` needs to be async as well?
No, it can be any pure function or IO. Both will get interrupted.
Kotlin Coroutine's structured concurrency. Cancelling a parent automatically cancels child jobs, unless explicitly handled not to. https://kotlinlang.org/docs/coroutines-basics.html
Stupidly, child cancellation cancels the parent scope as well, unless the scope opts out by including SupervisorJob.
Python async tasks can be cancelled. But, I don't think you can attach must context to the cancel (I think you can pass a text message), so it would seem the argument of what go suffered from would apply.
(I also think there's some wonkiness with and barriers to understanding Python's implementation that I don't think plagues Go to quite the same extent.)
The current meta is to use task groups and bubble up the exception that cancelled the coroutine/task.
Java's Virtual Threads (JVM 21) + the Structured Concurrency primitives (not sure exactly what's available in Java 21+) do this natively.
Also, a sibling poster mentioned ZIO/Scala which does the Structured Concurrency thing out of the box.
All mainstream languages have it in one or more forms (either direct task I/O cancellation, or cancellation tokens or I/O polling that can include synthetic events) since otherwise several I/O patterns are impossible
one of the reasons why i love writing control planes in Go.
in JS, signals and AbortController can replicate some of the functionality but it's far less ergonomic than Go.
https://github.com/ggoodman/context provides nice helpers that brings the DX a bit closer to Go.
C# has CancellationToken, but it’s just for canceling operations, not a general purpose context.
Not really, since they don't have `select`
There's a stop_token in some Microsoft C++ library but it's not nearly as convenient to interrupt a blocking operation with it.
[dead]
I think this post needs better examples to show case the issue, because right now the issue is not clear. Ideally you would need an example that uses the context.Cause function, see below
The contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.
Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.
Example that shows the approach as well as the specific issue raised by the post: https://go.dev/play/p/rpmqWJFQE05
Thanks for the post though! Made me think about contexts usage more
Agree. I am note sure I understand the premise of the article. You're now recording encountered errors twice, which can look like
Not only that, isn't this a "lie"? You're cancelling the context explicitly, but that's not necessary is it? Because at the moment the above call fails, the called-into functions might not have cancelled the context. There might be cleanup running later on which will then refuse to run on this eagerly cancelled context. There is no need to cancel this eagerly.Perhaps I'm not seeing the problem being solved, but bog-standard `return err` with "lazy" context cancellation (in a top-level `defer cancel()`), or eager (in a leaf I/O goroutine) seems to carry similar functionality. Stacking both with ~identical information seems redundant.
I am new enough to programming that I actually have no concrete idea what a context is; I just use it when a library asks for it.
> lemoncucumber
> it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace
I thought this was the whole reason to wrap errors, to know where they passed up the chain.
Funny how it seems no matter the subject, if Go is involved, errors get discussed.
Golang returning tuples but not having pattern matching is something I'll never get. I really feel it's a too dumbed down version of erlang/elixir, especially with this context passing business
Le sigh. "I don't wrap errors and so I don't know where my errors come from."
The code that justifies the special context handling:
Why not simply wrap that error with the same information?I have the same question, I am confused by the premise of this article. Now you're recording everything twice?
Never needed this. Nice to have but won't ever use it.
[dead]
You're kind of building a stack of exceptional cases... Wonder what that is :D