Re: [go-nuts] Re: Error handling

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 >

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

> 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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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,

Re: [go-nuts] Re: Error handling

@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

Re: [go-nuts] Re: Error handling

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()

[go-nuts] Re: Error handling

On Tuesday, 1 August 2023 at 18:14:56 UTC+1 DrGo wrote: Fair enough. But many would prefer shorter functions if there is no loss to explicitness or clarity. I don't think putting the assignment and return statement on the same line is very clear. I would prefer the compiler to enforce

[go-nuts] Re: Error handling

Fair enough. But many would prefer shorter functions if there is no loss to explicitness or clarity. On Tuesday, August 1, 2023 at 11:10:30 AM UTC-6 Stephen Illingworth wrote: > On Tuesday, 1 August 2023 at 18:06:25 UTC+1 DrGo wrote: > > Compare the following; which one would you prefer to

Re: [go-nuts] Re: Error handling

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: > > >

Re: [go-nuts] Re: Error handling

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

[go-nuts] Re: Error handling

On Tuesday, 1 August 2023 at 18:06:25 UTC+1 DrGo wrote: Compare the following; which one would you prefer to read a lot of? You've asked a fair question so you deserve an honest answer. Looking at the two examples, I would prefer to read the code in the first example. -- You received this

[go-nuts] Re: Error handling

Thanks. The keystroke saving is not the motivation. The aim is to reduce the code reader’s mental load. My approach allows for clearer code where the main program logic is not dwarfed by the error handling code while maintaining the explicitly of error handling and the possible error-induced

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

>> 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'

Re: [go-nuts] Re: Error handling

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

Re: [go-nuts] Re: Error handling

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

[go-nuts] Re: Error handling

Me too but I do not have high hopes On Monday, July 31, 2023 at 12:10:24 AM UTC-6 Mark wrote: > Given that this proposal is to reduce boilerplate, and assuming the > semantic issues could be solved, it seems to me that the 'return' is > redundant (i.e., could be implicit) and that 'orelse'

[go-nuts] Re: Error handling

Given that this proposal is to reduce boilerplate, and assuming the semantic issues could be solved, it seems to me that the 'return' is redundant (i.e., could be implicit) and that 'orelse' could be done with the existing 'else' keyword, i.e., ``` result, err := someCall() else rest, err ```

[go-nuts] Re: Error handling

I think the current error handling is just fine. For the extra typing, they invented keyboard snippets and such. But for this proposal, I would like to see how a return with multiple values would look to get a better understanding. ``` // translate this in the proposed solution? func

[go-nuts] Re: Error handling

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"

[go-nuts] Re: Error handling

err := io.Copy(w, r) *orelse* { w.Close() os.Remove(dst) return fmt.Errorf("copy %s %s: %v", src, dst, err) } My question still stands. Semantically, what value exactly does the "orelse" condition test is not equal to nil? - does it test the value from the preceding assignment? If so, is

[go-nuts] Re: Error handling

Good point Harri, This is what the correct version will look like using this proposal func CopyFile(src, dst string) error { r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src, dst, err) defer r.Close() w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s:

[go-nuts] Re: Error handling

Apologies if I am not understanding your question, but does not the compiler know the types of all variables (including the returned variables)? The compiler will emit code to execute the orelse block if the error variable (regardless of its name or concrete type) in the preceding statement is

[go-nuts] Re: Error handling

IMHO, you have used the irrelevant example (== 2nd code block) from Russ Cox's paper. The paper says: > This code is not nice, not clean, not elegant, *and still wrong:* like the previous version, it does not remove dst when io.Copy or w.Close fails. I want to compare your proposal with the

[go-nuts] Re: Error handling

Typo: should have said var foo error r, bar := os.Open(src) orelse return foo // does this do "if foo != nil { return foo }" ?? On Sunday, 30 July 2023 at 10:20:12 UTC+1 Brian Candler wrote: > On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote: > > orelse must return an error (ie satisfies

[go-nuts] Re: Error handling

On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote: orelse must return an error (ie satisfies the error interface); the specific type and variable name do not matter. But how does "orelse" perform the check in the first place? Does it look for the variable named in the return statement?

[go-nuts] Re: Error handling

thanks for the link. unlike the onErr approach, my proposal does not treat create special-status identifier; the orelse block is like any other else block On Sunday, July 30, 2023 at 1:31:09 AM UTC-6 Brian Candler wrote: On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote: I looked at the

[go-nuts] Re: Error handling

orelse must return an error (ie satisfies the error interface); the specific type and variable name do not matter. although on second thought.. I am not sure that even that restriction is necessary. On Sunday, July 30, 2023 at 1:02:04 AM UTC-6 Brian Candler wrote: Just to be clear: are you

[go-nuts] Re: Error handling

On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote: I looked at the long list of proposals to improve error handling in go but I have not seen the one I am describing below. There is a meta-ticket here: https://github.com/golang/go/issues/40432 Under the section "Simplifications of if err

[go-nuts] Re: Error handling

Just to be clear: are you hard-coding the variable name "err" into the semantics of "orelse"? That is, you can't assign the error return to a variable of any other name? I disagree that this makes the job of linters any easier than it is today. For example, if you'd written ...

[go-nuts] Re: error handling thoughts

The warning that I described is one presented by Visual Studio Code with the vscode-go extension. Color me stupid for having simply assumed it came from the compiler. Based on responses to this thread, I looked more closely, and found that Mr. Wagner is correct: it's coming from golint. I see

Re: [go-nuts] Re: error handling thoughts

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

[go-nuts] Re: error handling thoughts

Hi Steve, What's the compiler error that you're seeing? Here's a go playground example of your scenario. It doesn't seem to cause any issues but maybe I'm misunderstanding. https://go.dev/play/p/vvtrQTl7FSr Regards, Stephen On Thursday, 27 July 2023 at 16:04:19 UTC+1 Steve Roth wrote: > The

[go-nuts] Re: Error Handling

A package err2 helps you to implement the `errReturn` even though Go doesn't have macros or can return from the function enclosing the function checking the error. Please see the playground that does exactly that: https://go.dev/play/p/GvXFU1LbVvs However, I

Re: [go-nuts] Re: Error Handling Question

> 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

Re: [go-nuts] Re: Error Handling Question

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

[go-nuts] Re: Error Handling Question

Hi, On Friday, October 21, 2022 at 12:14:52 AM UTC+3 dple...@google.com wrote: > > var x0 float > try { >x0 = check DoSomeMath(check FetchSomething(), check ComputeSomething()) > } handle err { >log.Info("Unable to estimate initial approximation, defaulting to 1...") >x0 = 1 > } > //

[go-nuts] Re: [error handling] RFC 'else'

Also a lot of the proposals listed in the `Wrapping` section of https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/ On Wednesday, December 2, 2020 at 9:30:24 PM UTC+1 seank...@gmail.com wrote: > see also > > https://github.com/golang/go/issues/41908 >

[go-nuts] Re: [error handling] RFC 'else'

see also https://github.com/golang/go/issues/41908 https://github.com/golang/go/issues/37243 https://github.com/gooid/gonotes/blob/master/inline_style_error_handle.md On Wednesday, December 2, 2020 at 8:57:13 PM UTC+1 Oliver Smith wrote: > Do I understand correctly that "last return value is

[go-nuts] Re: Error Handling Best Practice (error wrapping)

Hi, There are two kinds of errors: user-facing error and developer-facing error. User-facing error is an error that is supposed to be relayed back to the end-users. It is usually stripped from sensitive information and is generally more verbose. On the other hand, developer-facing error are

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

| 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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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,

Re: [go-nuts] Re: error handling needs syntactical sugar

> > 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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

* 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

Re: [go-nuts] Re: error handling needs syntactical sugar

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,

Re: [go-nuts] Re: error handling needs syntactical sugar

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.

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

> > > 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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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 > }

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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,

Re: [go-nuts] Re: error handling needs syntactical sugar

>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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

[go-nuts] Re: error handling needs syntactical sugar

Agreed, Tim. This discussion helped me to realise that try/catch is pretty good; e.g. we never even bothered discussing this topic in our C++ code http://mechsys.nongnu.org/ at all... In the end of the day, we want to treat ALL errors (obviously...). Go is great that we have two approaches.

[go-nuts] Re: error handling needs syntactical sugar

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 cluster together you can. You guys make is sound like go style

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

...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

[go-nuts] Re: error handling needs syntactical sugar

Since *defer* "is the last thing to happen", I think this code is all right: func something() (x int, err error) { watch err != nil { return } res, err = acquireResource() defer func() { if err == nil { err = res.Close() } }() err =

[go-nuts] Re: error handling needs syntactical sugar

Hi, yes we need the check condition you had before in defer. That seems fine. But there may be some other problems I haven't thought of. Cheers -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: error handling needs syntactical sugar

What about? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightway (because

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return

[go-nuts] Re: error handling needs syntactical sugar

I've been doing something like this for long chains where "handle error" is the same: func something() (x int, err error) { defer func() { if err != nil { // handle error } }() res, err = acquireResource() if err == nil { defer func() {

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

Re: [go-nuts] Re: error handling needs syntactical sugar

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

[go-nuts] Re: error handling needs syntactical sugar

Fair enough. This would be perfect. Cheers On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10, marti...@programmfabrik.de wrote: > > Dorival, > > I think we can celebrate already if we achieve anything with this > discussion. Let's not ask for too much, plus let's not make it too >

[go-nuts] Re: error handling needs syntactical sugar

Dorival, I think we can celebrate already if we achieve anything with this discussion. Let's not ask for too much, plus let's not make it too complicated. I think your proposed "watch err", hides too much and does too little. You can simply write (the inline code editor is broken, BTW) func

[go-nuts] Re: error handling needs syntactical sugar

Hi Martin; What about two commands "*watch*" and "*watchif*"? The first works as the "*var*" command and the second as the "*if*" command. "*watch*" does: 1. In a function with *error* as an output (anywhere): returns in case the *err* declared with *watch err* (or *watch myerror*)

[go-nuts] Re: error handling needs syntactical sugar

Hi Dorival, thanks for supporting me with my idea. And yes, after writing my post yesterday I was thinking, "watchif" or even simply "watch". And yes, today I am more in favor of simply *"watch"*. And yes, we can constrain this to the context of one function (like defer), I am ok with that.

[go-nuts] Re: error handling needs syntactical sugar

On Monday, September 4, 2017 at 10:48:06 PM UTC+2, Tamás Gulácsi wrote: > > Why do you Prepare a statement if you don't reuse it? Just use a db.Exec. Just wanted to show a pattern which I see very often in Go code. Its not a working example, and I am not asking for improvements in that code.

[go-nuts] Re: error handling needs syntactical sugar

I forgot (again) to say that in this case the error would just be returned. In other words, `watch err` would just check if `err != nil` and then return. The other cases (test, main) would be as explained earlier (FailNow(), Exit(1)) On Tuesday, September 5, 2017 at 10:14:16 AM UTC+10,

[go-nuts] Re: error handling needs syntactical sugar

Hi, the `watch err` could also work in "APIs" that already return "error". For instance: package myapi func First() (err error) { watch err err = internalFunction(1,2,3) err = internalFunction(3,2,1) err = internalFunction(1,3,2) } On Tuesday, September 5, 2017 at 4:27:20 AM

[go-nuts] Re: error handling needs syntactical sugar

by the way, above, I was thinking of `watch` as a counterpart of `var`... On Tuesday, September 5, 2017 at 8:56:24 AM UTC+10, Dorival Pedroso wrote: > > Hi, > > Error management in Go is perfect! > > But I like the idea of `watch` (may we drop the `if`?) > > So, `watch` would work in the context

[go-nuts] Re: error handling needs syntactical sugar

Hi, Error management in Go is perfect! But I like the idea of `watch` (may we drop the `if`?) So, `watch` would work in the context of a function like `defer`. However, this would effectively become a `catcher` for errors (instead of `panics`) within the `defer` function, right? Also, I

[go-nuts] Re: Error handling best practices and unit testing complex error values

Use dependency injection and mock the objects to simulate the errors. In my opinion though, there is no need for an error to hold references to its underlying errors. Errors are just values. You take their values, add any additional information, and create a new error. You shouldn't need to

[go-nuts] Re: Error Handling

Just for clarification, the function fn() must return an interface for this to work. -- 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

[go-nuts] Re: Error Handling

Would a type switch do what you want ? err := fn() switch err := err.(type) { case nil: // all good case *MyCustomError: // do something custom default: // unexpected error } On Saturday, 26 November 2016 05:07:55 UTC+11, Parveen Kumar wrote: > > Hi Team, > > I want to catch my custom

[go-nuts] Re: Error handling and structured logging

At first I didn't like this idea, but the README has converted me to the possibilities. I have to admit I have a strong aversion to interface{}, and a map as well, but a lot of the other features are very interesting. I think, in a larger project, this may be just the thing for structured