In my opinion, the many options suggested for the new error handling scheme are bloated and unnecessary.
The defer statement is nice for placing closers next to openers, but I think if simply a partition of a function block was segregated to contain the handler code, probably nobody would be complaining about it anymore. The nicest and neatest way would be to use a keyword label. Something like 'recover:' or so. Labels don't get much use and usually are unnecessary if you change the structure of the loops and conditionals, but I don't think label users would complain about one special label. The recover block could also automatically provide the variable returned by the recovery function as well, removing more boilerplate. I have said it before, that I think the lack of a conditional return would also reduce the pain of error handling, combining a condition and the setting of return variables into one line, as, they are usually not long and thus fit in a line. My last thought about the error system is to do with the multiple returns. I think they could easily be automatically bundled into a struct when the receiver is a function and then the error value could be just variablename.error or something like this. On that topic, there also could be some use from defining a simple category set to define error types, such as severity, for example. This value could also be used by loggers to determine automatically what log level to print the error in. I am pretty sure there won't be much response to this, and I pretty much doubt I am going to be an early adopter of Go 2, so I will be writing a preprocessor that is configurable per project for what things it will implement. All of the things mentioned above can be easily, by any competent go programmer, expressed in the current syntax, it's just that it's tedious, and easy to procrastinate about it. I don't use panic except for conditions that should not happen, but it would be nice to compartmentalise all the error handling into a section alongside the code that can cause it. Incidentally, as I am currently working on a code sorting tool, the matter of godoc comments in particular is a major annoyance. The syntax is an abberation compared to the language, and I think it's nuts that golint doesn't just insert them in there, preferably like how many server default passwords are - funny little snipes at the admin. -- 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.
