Dnia 2020-11-11, o godz. 08:01:37 Jeremy French <ibi...@gmail.com> napisał(a):
> I know that's not realistic, and errors are a part of life. > My point is that they're not the main purpose of the code, and thus shouldn't > be taking up (up to) 75% of the code space when I'm trying to read what a > function does. There are fold spells to assist you in almost every editor otherwise suitable for coding. The psychological miracle of the verbose 'if err' block is that in many it spurs a wise laziness: "ok I have typed ife<tab>, I have my cursor inside the block, I am in scope, so why not to put my failure-dealing code here, and now". As for personal opinion: the very "return-if" sounds bad to me. It blatantly and loudly encourages "let others care 'bout that" attitude. In real code (that accidentally is not a kitchen-sink math library) dealing with *failures* is the bread and butter. In server's code piece it is not unusual to have some 10 lines of happy path and next 1000 just to deal with failures that *we think* may happen. Next 1000 will appear in the maintenance phase when heavy load will reveal failure scenarios we never thought may exist. The Go team's "try" proposal (I assume you read) was called off for exact same reason: "try" construct has been encouraging what many Go programmers assumed as a bad practice. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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/20201111210510.66da5dc5%40xmint.
