On Saturday, 8 February 2020 18:38:19 UTC, addi t0t08 wrote:
>
>
> Also, without any additional changes to the language. Go already allows
> separating statements with semicolons, so it would be even possible to do
> the following.
>
>
>
> f, err := os.Open(file1) ; pass err
> defer f.Close()
>
>
On Saturday, February 8, 2020 at 10:55:10 AM UTC-7, Brian Candler wrote:
>
> On Saturday, 8 February 2020 10:33:03 UTC, addi t0t08 wrote:
>>
>> No, 'pass' accepts an error type. in this case Foo function must return
>> an error type otherwise that would be a compile error.
>>
>>
> Ah I see: you ar
On Saturday, 8 February 2020 10:33:03 UTC, addi t0t08 wrote:
>
> No, 'pass' accepts an error type. in this case Foo function must return an
> error type otherwise that would be a compile error.
>
>
Ah I see: you are relying on the behaviour of errors.Wrap(nil, "dontcare"),
which is valid and retu
Your arguments against the current system seem very weak to me.
An editor can if you really care; fold on if err like it can on functions. I
would be strongly against hiding critical code in my company though.
For if err == nil or not return at all but log and try again etc. We now have
mult
On Saturday, February 8, 2020 at 2:14:31 AM UTC-7, Brian Candler wrote:
> On Saturday, 8 February 2020 07:02:34 UTC, addi t0t08 wrote:
>>
>> I think the keyword we are looking for is `pass`. Similarly, `pass` only
>> needs to return if err != nil.
>>
>> func writeSomething() error {
>>f, err
On Saturday, 8 February 2020 07:02:34 UTC, addi t0t08 wrote:
>
> I think the keyword we are looking for is `pass`. Similarly, `pass` only
> needs to return if err != nil.
>
> func writeSomething() error {
>f, err := os.Open("file.dat")
>pass err
>defer f.Close()
>
>f.WriteString(".
I see your point. I think it may be better to* narrow the scope* of what
should be improved.
For the most part, I like the simplicity of error handling in Go, but I
would very much like a less verbose
way to pass errors.
Technically we are not talking about handling the errors but we just want
To make an attempt at articulating why the error handling in Go is valuable
as-is, I note the following points:
- It is explicit, not hidden
- The default idiom highlights "error checking being done here" (Go
developers learn to look for lines "if err != nil".)
- It is possible to se
[sorry, posted a half post before]
You would want to have the error value at hand and do everything explicitly.
Using the try keyword really feels like going back to some other languages
where you would push everything up and then handle
a bunch of errors/exceptions in a "all eggs in one basket"
In case of multiple return values, it works similar to the original
proposal. This should work with multiple return values. As I stated, this
isn't a complete proposal.
On Thursday, February 6, 2020 at 10:55:35 PM UTC-7, MUNGAI wrote:
>
> I agree,
> Some of the proposals introduce more trouble
Hi,
as I recently mentioned in another thread, you can already use this error
handling stye without language changes:
https://play.golang.org/p/nDnXxPXeb--
(The function is named "check", not "try".)
See error decoration at the bottom.
--
You received this message because you are subscribed to
f, err := os.Open("file.dat")
try errors.Wrap(err, "couldn't open file")
You approach has some merits to it. In addition to that some error handling
solution needs to provide a way how to figure out what error happened, e.g.
openening a file could fail because it does not exist or because of
Hi,
I'd like to add that for this particular purpose, I find the keyword "try"
quite inappropriate. It makes sense in other languages, either with a
*catch* "counterpart" or not. But in those cases (at least those I'm aware
of), you're not trying a value, which makes no sense to me. You try an
act
I agree,
Some of the proposals introduce more trouble than the problem they are solving.
For example, the proposed try works only iff you are returning a single value
of type error. If you have more return values what happens?
--
You received this message because you are subscribed to the Goog
The original, rejected proposal was better because it was a built-in, not a
new keyword, so it didn't break existing tools. Otherwise I don't see a
difference.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and s
15 matches
Mail list logo
