On Fri, Aug 4, 2023, 13:57 Harri L wrote:
> Yes, we can handle Go errors without language changes; that’s true. But
> how we should annotate errors? The presented version of CopyFile leads to
> following 'stuttering':
> cannot copy '/tmpfs/play' to './tmp33/not-exist.txt': cannot create
> destina
Yes, we can handle Go errors without language changes; that’s true. But how
we should annotate errors? The presented version of CopyFile leads to
following 'stuttering':
cannot copy '/tmpfs/play' to './tmp33/not-exist.txt': cannot create
destination: open ./tmp33/not-exist.txt: no such file or
Thanks Miguel and I am not offended.. It sounds you like the proposal and
your comments were not about the proposal per se but about the cultural
issues surrounding change and fear of unnecessary growth; here we agree too.
On Friday, August 4, 2023 at 6:47:37 AM UTC-6 Miguel Angel Rivera
Notar
Ok, that is a point to have in mind.
El vie, 4 ago 2023 a las 10:37, Miguel Angel Rivera Notararigo (<
ntr...@gmail.com>) escribió:
> I understand, but there is a little difference, you can find code out
> there improving performance thanks to generics, I am not sure if we can get
> any performan
I understand, but there is a little difference, you can find code out there
improving performance thanks to generics, I am not sure if we can get any
performance improvement by using "orelse return err".
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts
> Generics add a lot of value
>From a personal point of view with the interfaces I got all the genericity
I needed to model solutions, and generics per se doesn't provide a new
approach to find solutions.
I Mean, you can solve the same old problems with or without generics...
Generics provides ano
It is not just resistance to change, it is about not adding new features
that add more complexity than value. I am pretty sure people will complain
about Go's error handling even if we use "orelse return err".
Generics add a lot of value, it shows the Go team is open to changes. But
imagine they a
As far as I see things there is always room for changes... but changes
doesn't come without some resistance.. That is natural...
> Go best features is the lack of new features.
What about generics? That was a major change... It was really necessary or
not is another topic.
El vie, 4 ago 2023 a
On Thu, Aug 3, 2023, 23:45 DrGo wrote:
> @Miguel Angel Rivera Notararigo
>
> Thanks for taking the time to write...
>
> In my proposal, people are free to add as much context as they want...
>
Yeah I know, I like your proposal, it is just how they handle errors in the
V programming language, alt
@Miguel Angel Rivera Notararigo
Thanks for taking the time to write...
In my proposal, people are free to add as much context as they want... but
as a demonstration, I am using the example from
Ross Cox's paper on error handling that is used by all error handling
proposals to show case their
func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()
w, err := os.Create(dst)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
if _, err := io.Copy(w, r); err != nil {
w.Close()
os.Re
Thanks Jan
Indeed the majority can be wrong but in this case the OLD smart minority
too wanted a way to improve things. This approach was in fact dictated by
their requirements
On Tuesday, August 1, 2023 at 2:10:57 AM UTC-6 Jan Mercl wrote:
> On Tue, Aug 1, 2023 at 1:47 AM DrGo wrote:
>
> > T
Thanks Tim for patiently explaining your perspective. Much appreciated.
Please see my reply to Marcelo H showing using real life code that the
outcome goes much further than replacing the err!= nil bit.
On Monday, July 31, 2023 at 7:20:18 PM UTC-6 Tim Casey wrote:
>
> >> You do not think thi
I think that the original Author has made a clear point. It has no sense to
denied that we often write a lot of times things like...
if (err != nil) {
return err
}
So, I understand that some people doesn't bother about that, and that is
okey. *But for those that doesn't like to write someth
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
On Tue, Aug 1, 2023 at 1:47 AM DrGo wrote:
> The verbosity of error handling is the number one concern for Go developers
> in the most recent survey.
That says something about those developers, about their preferences,
opinions, taste etc and that it differs from what the Original
Language Desi
>> You do not think this is a significant reduction in boilerplate?
I understand people having a complaint about the verbosity of error
handling. But, this follows C code error handling. So to me, it is not
all *that* bad.
I think the measurable reduction in boilerplate code is ' ; err != nil'
Thanks for the valuable feedback,
The verbosity of error handling is the number one concern for Go developers
in the most recent survey. So there is a need for doing something about
it.. except that there are many possibly conflicting requirements outlined
by the Go team.
The problem with the a
I do not think this reduces boilerplate code. This compacts it, which is
different.
I think any one-liner-return-on-err makes the language harder to debug. It
is very common breakpoints are set for exceptional cases, which tend to be
surprising. If the test and the return are on the same line t
It's not a compiler error, but OP is probably referring to golint.
FWIW I also prefer the `if v, err := fn(); err != nil { … }` form, in
general, but in cases like these I just write
v, err := fn()
if err != nil {
// handle error and return
}
// do thing with v
I honestly don't see a huge pro
> In many cases, including in the standard libraries, there are functions
that return errors and then accompanying functions with names like
MustFoo() that just call Foo() and panic if there's an error.
At least inside the standard lib, the uses of MustXxx document why they
behave the way they
Dan,
If it walks like a duck…
You make a great case why Go should have checked exceptions. If anything the Go
error handling model tries to be checked exceptions - every error should be
explicitly handled - without any of the conveniences of exceptions - common
blocks, stack traces and call st
On Mon, Sep 11, 2017 at 08:49:30PM +1200, Tim Uckun wrote:
> | However, what's great for avoiding straightforward failures becomes a
> | nightmare when your goal is to guarantee that no undefined behaviour
> | happens
>
> It seems to me that if this is your goal other languages are more suitable.
| However, what's great for avoiding straightforward failures becomes a
| nightmare when your goal is to guarantee that no undefined behaviour
| happens
It seems to me that if this is your goal other languages are more suitable.
Erlang for example is famous for it's error handling capability, elm
On Wed, Sep 06, 2017 at 11:00:08PM -0700, Tim Uckun wrote:
> Totally not a go programmer but here are my worthless two cents.
>
> I don't see anything wrong with the try catch paradigm, you can choose your
> granularity. If you want to check every call then you can, if you want to
> let a few c
The solution to Close returning an error, is to defer Close() and then have
a second Close() with error checking in the happy path.
I just wish the io.Closer contract would require, that this has to be safe
(= not panic). Luckily it is, for the vast majority of Closers at least.
On Fri, Sep 8, 20
>
> P.S. someone else proposed wrapper with error handling in defer.
> IMO it is as bad as watch - spooky, at distance, clunky.
>
That was me. My background is many years of C++ and it feels natural to me
(RAII). I follow the pattern: there must be defer Close immediately after
acquire action
Sure! I'm happy to listen to the experience of you all and to keep working
using the existent approach. Thanks, everyone. Dorival
On Friday, September 8, 2017 at 10:29:02 PM UTC+10, Marvin Renich wrote:
>
> * Dorival Pedroso [170908 02:08]:
> > The "watch" strategy would, of course, allow us to
* Dorival Pedroso [170908 02:08]:
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. clean up and so on).
>
> For instance:
> watch err != nil {
> // do the important things
> return err
> }
Except that "do the important things" often de
On Thu, 7 Sep 2017 17:03:06 -0700 (PDT)
Dorival Pedroso wrote:
> Wouldn't be great to have a "syntactical sugar" to make things (at least a
> little bit) simpler in our beloved Go language?
No. Proposed (*also by past me*) "watch" construct is bad for anyone
reading code, bad for code consiste
please replace:
"will return immediately to the [...]"
with
"will jump immediately to the [...]"
(sorry)
On Friday, September 8, 2017 at 4:07:35 PM UTC+10, Dorival Pedroso wrote:
>
> Hi Dave,
>
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. cl
Hi Dave,
The "watch" strategy would, of course, allow us to do the important steps
you've mentioned (e.g. clean up and so on).
For instance:
watch err != nil {
// do the important things
return err
}
The watch basically "groups common tasks".
For example, If we have so many tasks, we c
>
>
> Wouldn't be great to have a "syntactical sugar" to make things (at least a
> little bit) simpler in our beloved Go language?
>
>>
>>
no, I don't think so.
Something that few in in this thread have focused on is the most important
part of the go error handling story happens *before* the `
Yes, Nigel! try/catch in Python may at times looks uglier that err != nil.
I think the reason try/catch didn't bother us in C++ is that we had lots of
macros to simplify the work...
In Go, we don't have macros but we don't need to wrap things with "try" and
just need to "recover" panics, I thin
On Thu, Sep 7, 2017 at 4:00 PM, Tim Uckun wrote:
> I don't see anything wrong with the try catch paradigm,
Try-catch makes for shorter code when you're just passing the buck,
but it can be quite complicated when you actually need to handle the
buck.
My showcase example for this is the exception-
On Thu, 7 Sep 2017 05:00:18 -0700 (PDT)
martin.r...@programmfabrik.de wrote:
> lhow about this, and it is a construct which can be used not only for
> errors:
> watch err != nil {
> yo1, err = do_stuff1()
> yo2, err = do_stuff2()
> yo3, err = do_stuff3()
> } then {
> // handle your error
> }
W
On Thu, Sep 7, 2017 at 2:41 PM, Tim Uckun wrote:
> >I *like* the way go does error passing, *because* it's constrained to
> handle errors explicitly.
>
> But it doesn't though. You can completely ignore the errors if you want. >
>
This seems to be, at best, a nit-picky uncharitable reading of wh
Hi Tim
If you want halt the app, you should call panic, that's already a go
built-in. Think it would apply to your proposal as well, despite i do not
agree with it.
Cheers snmed
Am Donnerstag, 7. September 2017 14:42:12 UTC+2 schrieb Tim Uckun:
>
> >I *like* the way go does error passing, *bec
>I *like* the way go does error passing, *because* it's constrained to
handle errors explicitly.
But it doesn't though. You can completely ignore the errors if you want. >
>TBH, no. Not only do I not know what this is supposed to be doing
(err.pop? of what? Why are we assigning to error? What is
I'd hate to debug this: which function has returned the error? What failed,
what succeeded?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr.
On Tuesday, September 5, 2017 at 10:39:05 AM UTC+2, Rob 'Commander' Pike
wrote:
>
> If you find that lines like if err != nil are a significant fraction
> of non-test code, your code probably needs a better error handling
> strategy, not a language change. I have done measurements in the past
>
On Thu, Sep 7, 2017 at 8:00 AM, Tim Uckun wrote:
> I don't see anything wrong with the try catch paradigm, you can choose
> your granularity. If you want to check every call then you can, if you want
> to let a few cluster together you can. You guys make is sound like go style
> error handling is
Hi Michael,
I fully agree with handling each single error ("health issue") as they are
discovered.
The idea of "watch" is NOT to replace this procedure.
It's just a "syntactic sugar" to do what you are doing already.
Cheers.
Dorival
--
You received this message because you are subscribed to
...Go is not perfect. But there is subtle magic in this error business.
Developers should look closely at errors. Imagine handling them as if you
were a doctor and the error was a child's symptom or a test result. Choices:
1. Ask them how they feel, ignore it. Do a test, ignore it. Effectively you
Or you know, just panic ... errors as value are a convention, not a
language construct.
panic/defer ARE a language construct. I personally give the choice in my
API, Must prefixed methods that panic or regular methods that return an
error.
The obvious advantage of panics is that the developer a
Thanks again, Rob.
The blog post (https://blog.golang.org/errors-are-values) does shed some
light.
One of the ideas is to hold the *err* variable in a structure. I will
definitively use this more often (I do have many structures and never
thought of doing this!)---Thanks!
The other idea is to
Exactly: a good amount of "if err != nil" appears in my tests (334 out of
569). I'll try to re-think the other cases...
(e.g. https://github.com/cpmech/gosl/blob/master/la/blas2.go)
No complaints here, by the way! Just enjoying this marvellous language!
I'll read the blog post.
Cheers.
On Tues
If you find that lines like if err != nil are a significant fraction
of non-test code, your code probably needs a better error handling
strategy, not a language change. I have done measurements in the past
and although people complain a lot about the presence of that
statement, it shows up much les
48 matches
Mail list logo
