This is not necessarily true. A single call may return a variety of
errors. Otherwise a simple (ok bool) would be enough.
On Tue, 2019-07-09 at 15:49 +0200, Nicolas Grilly wrote:
> On Tue, Jul 9, 2019 at 3:36 PM Wojciech S. Czarnecki >
> wrote:
>
> > Because given piece of contemporary
On Tue, Jul 9, 2019 at 3:36 PM Wojciech S. Czarnecki
wrote:
> Because given piece of contemporary production code may succeed in
> only ONE way, but it may FAIL in many ways.
If a piece of code may fail in many ways, then it will probably have
several if blocks, and try will not be used. I
On Tue, 9 Jul 2019 15:19:22 +0200
Nicolas Grilly wrote:
> I agree that the "sad" path is as important as the "happy" path, but I
> wouldn't say it's more important to the point of dominating the number of
> lines in a function. In some functions, 2/3 or 3/4 of the lines are
> dedicated to error
On Tue, Jul 9, 2019 at 2:00 PM Ian Davis wrote:
> It's quite a bit more than a just new function since it brings some new
> behaviours that we don't have for functions in Go at the moment:
>
> 1. like panic it interrupts its caller's control flow
>
> 2. It may only be used within
On Tue, Jul 9, 2019 at 1:57 PM Jan Mercl <0xj...@gmail.com> wrote:
> It's not verbosity. It's error handling. And because error handling is
> usually not the happy path, it's good when it stands out clearly. That
> improves readability as the important part catches attention easier.
>
I agree
On Tue, Jul 9, 2019 at 2:03 PM Henrik Johansson wrote:
>
> Not sure if anyone has already mentioned the possibility that "try" could
> actually improve error handling
> by simply removing much of the tediousness. Both reading and writing all the
> error checks becomes a
> nail in my eyes even
Not sure if anyone has already mentioned the possibility that "try" could
actually improve error handling
by simply removing much of the tediousness. Both reading and writing all
the error checks becomes a
nail in my eyes even if realize that it is very important. What if "try"
could take some of
On Tue, 9 Jul 2019, at 11:43 AM, Nicolas Grilly wrote:
>
>> So why complicate the language with a new keyword which has really no
>> purpose.
>
> As mentioned in the proposal, try is not a new keyword, it's just a new
> built-in function.
It's quite a bit more than a just new function since
On Tue, Jul 9, 2019 at 1:48 PM Nicolas Grilly wrote:
> The goal of the try proposal is not to "save a few keystrokes". The goal is
> to reduce error handling verbosity when reading code.
It's not verbosity. It's error handling. And because error handling is
usually not the happy path, it's
On Thursday, July 4, 2019 at 5:14:40 PM UTC+2, Michael Ellis wrote:
>
> In my view, saving a few keystrokes is not the reason to support such a
> test. I've already got an editor snippet that generates a default "if err
> != nil ... " clause.
>
The goal of the try proposal is not to "save a few
On Thursday, July 4, 2019 at 10:55:50 AM UTC+2, Slawomir Pryczek wrote:
>
> going to turn code into unreadable, fragmented mess
>
Do you really think that replacing:
f, err := os.Open("file.txt")
if err != nil {
return err
}
By:
f := try(os.Open("file.txt"))
Will "turn code into
On Thursday, 4 July 2019 22:45:40 UTC+2, mh cbon wrote:
>
>
> less stupid the oprator could infer various things based on static rules,
> very much like value/ptr initialization implies a few static rules.
>
> on os.IsNotExist(err):
> on err == io.EOF:
> on err.(*os.PathError):
>
>
Sorry, they were posted in another similar thread:
https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/Rk02duq6CQAJ
https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/37-RUc-7CQAJ
> On Jul 4, 2019, at 3:45 PM, mh cbon wrote:
>
> yes the zero value test seems akward from here also.
>
yes the zero value test seems akward from here also.
It appears to me the proposal is sub optimal because,
to put it clear, the operator is dumb.
Its a disguised if with a one lin block statement.
I believe it would gain a ton more usability by being smarter to allow for
more useful
As noted by Aston, Jones, et al, the proposal is combining two ideas that
are separable:
1. Allowing one-liners. I like the idea of leaving that to gofmt. I'd be
ok with requiring braces and allowing gofmt to make the decision to format
in one line or three using some reasonable
On one side, it's 1000x better than the other error handling specs, at
least it isn't going to turn code into unreadable, fragmented mess. On the
other, Aston seems to have a point, it's just replacing one-liner... and
it's not that great at all because with "if" you know what it's doing
Any form of restraining gofmt has my vote. One that I despise is ruining:
switch v {
case ‘a’: doA = true
case ‘b’: doB = true
:
case ‘z’: doZ = true
}
Just had this two days ago. So sad to see it balloon up
On Wed, Jul 3, 2019 at 11:36 AM Aston Motes wrote:
> This proposal is not very much
This proposal is not very much different from a one-liner
if err != nil { }
It's just 10 more characters. Granted, gofmt won't leave the one-liner
formatted that way, but it's not much more typing and comes with the
benefit of not needing a new keyword.
One variation on this proposal that is a
I like this. A lot.
It's clean and explicit. The reader only needs to understand that 'on' is
a test for a nil value (vs 'if' which tests for boolean true).
On Tuesday, July 2, 2019 at 3:57:24 PM UTC-4, Liam wrote:
>
> This proposal has attracted modest attention from the Go team...
>
19 matches
Mail list logo
