Some time ago, after going through a very similar design (really, even had the catch clause in there), I have arrived at a more generalized version of it. That contemplation (still available at https://didenko.github.io/grab/grab_worth_it_0.1.1.html ) was very much unaccepted here.
Well, I actually do not remember if it was posted here or in golang-dev. On Wednesday, August 29, 2018 at 5:16:42 PM UTC-5, Liam wrote: > > Re the Go2 Error Handling proposal > > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md > > I have posted this feedback > https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e > > Which contains an alternate handler concept. Please let me know if you > think this merits its own github.com/golang issue. > > A *flag identifier *indicates errors of various types. This also allows > chaining of handlers with the same flag name. There are options for the #flag > syntax, e.g. flag!, $flag, @flag, etc. > > func f() { > v, #ret := returnIfError() // #ret can be any type; any non-zero value > for it triggers its catch > v, #fat := fatalIfError() // #ret, etc are (probably) not local > variables > v, #wrt := writeOnError() > if v != nice { // new scope > #fat = MyError{msg:"!nice", ...} > catch fat error { debug.PrintStack() } // no return/exit; chained > with next catch fat > } > #packageFlag = anotherError() // invokes package-level handler > > catch ret error { return ret } // if type is error, type > name could be optional > catch fat error { log.Fatal(fat) } > catch wrt error { con.Write(...); return nil } // return/exit required in > last handler on chain > } > > catch packageFlag error { ... } // package-level handler; packageFlag is not > a package variable > > -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
