I don't know if it qualifies as "best practice" but I think it would
certainly qualify as convention to put the error as the last returned
value. It is also extremely common to name the error "err", though that
would have little impact on API consumers as they can rename it whatever
they want.
As a firm advocate for Go, I do not think Go is a good choice for what
you're trying to do. Maybe if you wanted to just use a JIT compiler for
your scripts? Since Go compiles so fast, you may not even notice the
compile time for small, 500-line "scripts". Otherwise, if it has to be
interprete
This:
> "I want to be able to mock every function in my library."
is a bit confusing. Normally, you want to mock the functions that your
library calls, not your own library functions.
Other than that, this seems pretty doable.. Can you give some more
clarification as to what aspect is giving you
I understand the problem you are trying to solve, and it's valid, I think.
But this solutions "feels" bad and very un-Go-like. Usable zero values is
a feature in Go. Whether you agree with that or not, it's a selling feature
of the language and clearly something that was/is important to the Go
I don't have any insight in trouble-shooting your exact issue, but I too
would like a simple, reliable way to exclude packages from -coverpkg=./...
Feels like relying on shell scripts (which is what a google search
recommends) is a) fragile, and b) not particularly cross-platform.
On Tuesday, M
t. I was more just answering
Mike Schinkel's question about why it would be useful.
On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote:
> On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote:
>
> What I find valuable is to be able to accept an enum as a paramet
What I find valuable is to be able to accept an enum as a parameter to a
function, and know that it will be one of several approved values (e.g.
month of the year), without having to have boiler plate to check or throw
errors if it's not one of the approved values. It's checked at
compile-time
I really think the testability issue is the biggest one. Generally,
testing the main package iscumbersome at least. So it's reasonable to
say, "I'm not going to test the main package, but I will keep it so simple
that it is impossible for a bug to exist in there." Then everything else
in
I don't think this argument holds much weight. I understand and agree that
the majority is not always correct. But then what was the point of the
developer survey, if that data is irrelevant? Isn't the existence of the
developer survey an implicit statement by the Go team that they care about
Also, errors are values, which means - although uncommon - a function could
return two or more error values. Which would orelse evaluate? Even if you
arbitrarily chose one, that would violate the explicit vs implicit code
flow principle.
My sympathies, OP. I too hate the "if err!= nil" boi
Scrolling in code is bad - a necessary evil, obviously, but evil
nonetheless. Vertical scrolling is bad because it causes what we were
looking at to move and our eyes have to track and/or reacquire what we were
looking at. It's obviously possible, but on the micro-scale it's expensive
when yo
I wouldn't think that UML is unpopular, so much as it's not as helpful as
other languages. UML is especially useful in OOP, which Go is not, at least
not specifically. And I also think UML can tend to push you into certain
paradigms of thinking or design patterns, whereas maybe Go tends to have
Nice! Thanks.
On Mon, Mar 15, 2021 at 10:36 PM Wojciech S. Czarnecki
wrote:
> Dnia 2021-03-15, o godz. 10:44:50
> Jeremy French napisał(a):
>
> > So it seems like the logical solution would be to create a test that
> runs a
> > benchmark and makes sure the benchmark
I was really trying not to weigh in here, mostly because it's a decision
that has been decided, so there's not a lot of point in continuing the
discussion, and yesterday it seemed like the thread would die, yet... it
continues.
For context, I was against the generics proposal, primarily because
much if you don't have DataDog, Prometheus or Jenkins.
>
> -- Marcin
>
> On Mon, Mar 15, 2021 at 10:45 AM Jeremy French wrote:
>
>> I keep running into this solution to a particular problem, but when I go
>> to search on how to do it, I find that not only are ther
I keep running into this solution to a particular problem, but when I go to
search on how to do it, I find that not only are there seemingly no
solutions out there in search-results-land, there doesn't seem to be anyone
else even asking about it. This then leads me to suspect, that I'm going
a
This conversation makes me want to consider whether there's a way to solve
the problem that Generics solves, but solve it in a different way. This
discussion bears a lot of similarity to the argument about inheritance, and
Go solved that issue rather elegantly with interfaces - describe the
behavio
If Java and C++ were the perfection of computer language evolution, then
there would be no need for Go. Using your predecessors as the gold standard
makes no sense, because if they were, then no other iteration would be
necessary. We wouldn't be having this discussion, because there would be no
Go.
I'd like to second the notion that the argument "if you don't like them,
don't use them," is an invalid argument. Anyone who's been in the game for
any length of time knows that more than we'd like, we're repairing someone
else's code, as opposed to writing our own from scratch. If there is a
On Wednesday, November 11, 2020 at 2:09:19 AM UTC-5
axel.wa...@googlemail.com wrote:
> On Wed, Nov 11, 2020 at 2:43 AM Jeremy French wrote:
>
>> I certainly can't speak for the whole community, but for me, the key word
>> here is verbosity. I don't care (too much
;value"]
>> returnif !ok, errors.New("Oh no! Missing key 'value'!")
>>
>> Another thought: Should returnif allow a statement before the boolean
>> expression like if does?
>>
>> returnif value, ok := myMap["value"]; !ok, errors.Ne
Hm, yep. Very similar. Interestingly, the only cohesive objections I can
see in those threads are to the minor details that are different from what
I'm saying. Still, though - at least the idea has been presented before.
Jeremy French
607-444-1725
On Mon, Nov 9, 2020, 2:57 PM Ian Lance T
First, the caveat. I know error handling is a long-standing discussion. I
know there has been lots of debate on error handling, and it can seem like
there are no more new ideas to be had on the topic. And I have looked at
several/most of the most popular proposals, and there are quite a few t
23 matches
Mail list logo
