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

In the C world one can do things like int foo(char *infile, *outfile) { int n = -1, in, out = -1; ... if ((in = open(infile, O_RDONLY)) < 0 || (out = creat(outfile, 0666)) < 0 || (n = read(infile, buf, sizeof buf)) <= 0) goto err; ... return 0; err: close(in); if (out

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

I think Rob is really on to something here and I have seen it evolve in my own programming. I tend to make simple things "flatter" and model things around cores that don't error out and just at the boundaries evaluate and possibly produce an error. Is that "monadic"? Anyway it gets easier if you tr

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

Wojciech, you're right: It'll effectively work as a "catch" (or "recover"); e.g. something like: defer func() { if err := recover(); err != nil { fmt.Printf("ERROR: %v\n", err) } }() The only difference is that we wouldn't have to "throw" or "panic". The compiler would just "wat

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

On Tue, 5 Sep 2017 00:20:09 -0700 (PDT) Dorival Pedroso wrote: > I realised I've written 569 "if err != nil": > And I've written 231 error messages > And I have a feeling that I've done only 20% of the error messages... Factor 2,46 so far. It directly *proves* that any 'watch' construct would g

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

On Tue, 5 Sep 2017 00:11:02 -0700 (PDT) martin.r...@programmfabrik.de wrote: Ooops, bad paste to playground ['fail' logic leaked into https://play.golang.org/p/ig-KOi92Ku] Fixed is at: https://play.golang.org/p/dHE2wlwgIL -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this mes

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

On Tue, 5 Sep 2017 00:11:02 -0700 (PDT) martin.r...@programmfabrik.de wrote: >- Make it easier to read and follow As a former "inventor" of the "watch construct" I may say that I was wrong. It is NOT easier to read and it is much harder to follow. I was then, as you are now, I was angry abou

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

Martin, Certainly! I have (in https://github.com/cpmech/gosl): Total number of files = 430 Total number of lines = 73470 (NOTE: there are Go (30%), C (30%), C++ (16%), and Fortran (8%), plus Python and R files in there...) On Tuesday, September 5, 2017 at 5:24:28 PM UTC+10, marti...@programmfabr

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

Dorival, thanks for counting your error calls, but without any other number showing the size of your project they cannot really put in perspective ;-) And I think *watch* should not only be function bound, but bound to the current scope, same as *var*. Martin On Tuesday, September 5, 2017 at

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

And I've written 231 error messages (I use a function called chk.Err() to do so): find . -iname "*.go" -exec grep -inH "chk.Err" {} \; | wc -l 231 See the messages here: https://gist.github.com/cpmech/d2e36dcbe277cd72605f3732d79c798b And I have a feeling that I've done only 20% of the error me

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

I'm working on a Go project right now and I realised I've written 569 "if err != nil": find . -iname "*.go" -exec grep -inH "if err != nil" {} \; | wc -l 569 On Tuesday, September 5, 2017 at 4:57:45 PM UTC+10, Axel Wagner wrote: > > > > On Tue, Sep 5, 2017 at 8:49 AM, > > wrote: > >> Axel, >>

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

Hi Axel, thanks for your input. I think Martin's proposal is all right. We'll certainly keep suggesting all good practices to handle errors (I myself have tons of error messages + handling..). Go is perfect in doing this. We can even mimic "try" + "catch" with "panic" + "recover" (although I r

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

> > > You don't. But it's a bad idea. And "I want to make writing bad code > easier" isn't a very convincing argument for a language-change. > Ok, than I want to - Make it easier to read and follow - Make it possible to handle errors in one place instead of 10 I see you point, and yes, I

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

On Tue, Sep 5, 2017 at 8:49 AM, wrote: > Axel, > > thanks for the reply. > > As I already replied to Tomas, I am not looking for improvements in this > particular case where I need to call an SQL database. > > An no, I dont want to wrap all function I use into something which > collects the error

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

Axel, thanks for the reply. As I already replied to Tomas, I am not looking for improvements in this particular case where I need to call an SQL database. An no, I dont want to wrap all function I use into something which collects the errors for me. Let's say you want to log & panic & exit a

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

See, e.g. here or here for previous discussions of very similar (even mostly identical) proposals. What I always dislike about these kinds of proposals is,

[go-nuts] error handling needs syntactical sugar

Why do you Prepare a statement if you don't reuse it? Just use a db.Exec. But concretes aside: error handling IS important! But if such code bothers you, create some helper type / function: see one Andy+Brad pair programming video where they create an errWriter struct which is an io.Writer, and

[go-nuts] error handling needs syntactical sugar

Hi guys, at first I though I really like the idea of how Go deals with error management and handling, but the more Go code I look at or try to program, the more I get scared about checking errors every second line in every given block of code. Take a look at this example here from "Build Web A