My point is that an example of a 'best practice' shouldn't make the reader think:
Oh, that's a kludge to get around a design decision in the language.
In his example, he uses a one-off type to isolate the caller from having to explicitly
check if each individual write failed. I got no problem with that.
But it seems like it a work-a-round.
It's just an odd choice for an example. The take-a-way seems to be that the basic class
libraries need a wrapper that makes them easier to work with and that, you the developer,
should build these wrappers so you know exactly what the policy is.
> My point is that an example of a 'best practice' shouldn't make the reader think: Oh, that's a kludge to get around a design decision in the language.
I would think that some of the most important best practices would relate to the best means of dealing with situations where the approach users coming from other languages might naturally seek to apply are not the most appropriate, either because the other-language feature they are likely to have used does not exists (or works differently) or because of features in the target language that allow a better approach than in other languages.
> In his example, he uses a one-off type to isolate the caller from having to explicitly check if each individual write failed. I got no problem with that.
You'd do that if the library function threw exceptions, too. Eliminating repeated try/catch blocks (or calls to inline functions with deferred recover calls in go) and eliminating repeated if/then blocks are pretty much the same thing.
In his example, he uses a one-off type to isolate the caller from having to explicitly check if each individual write failed. I got no problem with that.
But it seems like it a work-a-round.
It's just an odd choice for an example. The take-a-way seems to be that the basic class libraries need a wrapper that makes them easier to work with and that, you the developer, should build these wrappers so you know exactly what the policy is.