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 multiple cases and less transparent code. Hiding this away for "legacy use" is creating bigger problems than you are solving. It is no longer transparent to newbies how to do this crucial thing. IMO The "try" keyword is a confusing choice, it does not read well. Test might be better or if err !=nil; return syntax change even better but I don't see the point and can't imagine the ramifications. Having multiple ways of doing the exact same thing should be avoided, where possible. The only part that I see of use is handing callers() or stack trace to users on a plate, if it achieves that? OTOH the output might be more confusing....undecided. I wouldn't support this personally, not that I really count much. It doesn't seem to be solving a problem but creating them and rather solving a debatable preference. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/58D73180-B97A-430C-908F-E40DFBF7B567%40gmail.com.
