4 ms·
A super important principal for large code base is locality. I should be able to look at a function and understand everything about its possible code paths. Exc
by lanstin 6y ago
A super important principal for large code base is locality. I should be able to look at a function and understand everything about its possible code paths. Exceptions make this impossible (most of my experience with exceptions coming from C++ and Python). People that think like me would forbid exceptions every where.
- one2know 6y agoreturn values don't say anything about possible code paths. If you are saying the function should document what could go wrong when it is called, Java solved this 24 years ago when each method lists the exceptions they throw. If you need to know what the back trace/call stack was when the error happened, well that is stored in the exception. People that use return codes simply don't check every possible value, otherwise they would see that it increases program length by at least 50% and makes the code unreadable. A common pattern in Go is this if (err == MY_ERROR) { log my error; notify user; return MY_ENCAPSULATING_ERROR_CODE } for high quality code this has to occur for every function call in the entire codebase. So you'll get huge functions which are mostly 'if' statements checking error codes, logging the results, and returning another error code that has to be checked again one step up the call stack. moving from c++ to java 20 years ago it was clear that the c/c++ community didn't really know what they were doing in this regard. A lot of c/c++ dogma boilerplate code was holding it back. Too bad some of it made it into golang.
- lanstin 6y agoExplain the Java services that only ever return an HTTP 200 and either return the proper XML response or a java stack trace formatted into HTML. And my point is those if statement are wanted by the people that write high reliability software in C. There just isn’t a substitute for thinking about errors. Even well done exception throwing systems will specific “this layer can throw, this middle layer won’t worry about errors, then this higher layer will restart or retry or whatever”. And in go within one layer you can usually have all those steps in one function and for error cases with the same handling just check for if err != nil. When I read code without explicit error handling I worry. I guess this debate is probably an aesthetic debate, and different type of code have different urgency. The extra check for error return is like the check for parameter correctness at the top of a function, which is common in robust C code. You can’t trust the callers too much and better to log an error than terminate the process.
- apta 6y ago> And my point is those if statement are wanted by the people that write high reliability software in C. Because that's basically the only way of handling errors in C. That kind of software is written despite C's poor error handling, not because of it, and frankly, C is not the best example in writing high reliability software. Undefined behavior is a huge issue with it.
- apta 6y ago> I should be able to look at a function and understand everything about its possible code paths. Any golang function can panic, so you always have to account for it anyway.