On Thursday 15 February 2024 at 10:31:40 am UTC+11 Jeremy French wrote:
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
On Wednesday 14 February 2024 at 10:23:37 pm UTC+11 Mike Schinkel wrote:
I cannot speak for others but I can tell you why I keep my `main()` small:
1. I prefer to put as much logic into reusable packages as I can, and
`main()` is not reusable outside the current app.
This is understandable.
I see quite a few modules out there where they seem to be putting in as
little into the main package as possible. Literally they will sometimes be
a few lines:
```
import foobar
func main() {
os.Exit(foobar.Run())
}
```
Yet then go on to do all the things I would've thought are the domain of
On Monday, 2 October 2023 at 12:00:35 am UTC+11 Axel Wagner wrote:
On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard
wrote:
I've been thinking about this point as well lately. I think I understand
(at least some of) the conditions under which
you would call a panic(), but I still don't quite
I've been thinking about this point as well lately. I think I understand
(at least some of) the conditions under which
you would call a panic(), but I still don't quite grok why it's better than
returning an error if that error is properly
handled. If I panic(), then no defer() statements will
where it's implemented, which risks
misunderstanding the purpose of it entirely.
On Wednesday, 27 September 2023 at 12:56:50 am UTC+10 burak serdar wrote:
> On Tue, Sep 26, 2023 at 6:18 AM Jerry Londergaard
> wrote:
> >
> >
> > Do I need to be re-defining this interface everywhere
Hello,
I'm trying to understand if I'm going overboard with defining interfaces
where they are used (i.e am I re-defining them nu-necessarily). Here's an
example. The interface is passed down from A->B->C where C (and only C)
calls the DoThing() method of the interface:
Thu, 21 Sept 2023 at 12:40, burak serdar wrote:
> On Wed, Sep 20, 2023 at 5:04 PM Jerry Londergaard
> wrote:
> >
> > Are you comfortable though, *relying* on this behaviour down the stack
> to enforce the timeout that was declared
> > further up the stack (leaving potent
s
like a bug in that code (i.e not the callers responsibility).
On Thu, 21 Sept 2023 at 05:34, burak serdar wrote:
> On Wed, Sep 20, 2023 at 7:47 AM Jerry Londergaard
> wrote:
> >
> > When using a context.WithTimeout, I always felt that it should be the
> fu
When using a context.WithTimeout, I always felt that it should be the
function where the context was created should be the one that ensures that
it (the current function) does not block longer than intended. That is to
say, it should call context.WithTimeout(), and then run the subsequent code
10 matches
Mail list logo
