3 ms·

I see "real" exception support as an attempt to solve deficiency of resource management on errors in a shared memory model. But it never actually solves it, onl

I see "real" exception support as an attempt to solve deficiency of resource management on errors in a shared memory model. But it never actually solves it, only puts a burden on people to manually deal with it (sort of like manual memory management) and introduces a lot of accidental complexity into everything it touches. Such problems are way better solvable with killable isolated processes and message passing (actor model). Otherwise discouraging use of panics and primitive support for exceptions is good enough. It helps avoid too much manual error propagation in certain rare cases. Real exceptions are still not a solution though.

candiodari 8y ago
> and introduces a lot of accidental complexity into everything it touches No it doesn't. That complexity is there. What you mean to say is that it makes it more obvious (and far easier to debug) when things go wrong. Manual error handling ... let's just simplify that to "igoring all errors", and if you aren't convinced, looking at a few Go repositories on github will drive the point home. So all "no exception system" really does is switch the default from "crash on error" to "ignore error". In C, before Java, this caused quite a few disasters with VERY bad error behavior (like silently deleting/overwriting all data, or starting a new data file, which you now get to merge manually with the one it ignored, for instance) ... in fact unix C tools are still (and, imho, justifiably) famous for their "nuke the whole world upon encountering a slight syntax issue" behaviors. Besides, the Go authors' own tools usually crash (log.Fatalf), but without stacktrace or unwind, on 90% of errors. That's, of course, even worse than exceptions crashing out of the program in several ways: 1) You have no idea what happened. We're back to grepping the source code for the last string it printed and praying you find something. Stacktraces ! GIVE ME BACK MY STACKTRACES. 2) Cleanup does not happen (!!!!!) with log.Fatalf. I repeat: NO CLEANUP WILL HAPPEN WHEN CALLING log.Fatalf. DO NOT USE log.Fatalf if your program has done anything at all !!!!!!!! The go authors themselves, especially should have gone through the exercise of, at EVERY error check, figure out what needs unwinding (file closing, ...) and then doing the same at higher levels of the stack as well. Needless to say, NOBODY, not even Rob Pike himself, has done that. As far as I can tell, not even once. 3) we all know how these bugs get fixed. By changing "crash out" to ignore. And frankly, given point 2, I will actually call it an improvement.

candiodari 8y ago

> and introduces a lot of accidental complexity into everything it touches No it doesn't. That complexity is there. What you mean to say is that it makes it more obvious (and far easier to debug) when things go wrong. Manual error handling ... let's just simplify that to "igoring all errors", and if you aren't convinced, looking at a few Go repositories on github will drive the point home. So all "no exception system" really does is switch the default from "crash on error" to "ignore error". In C, before Java, this caused quite a few disasters with VERY bad error behavior (like silently deleting/overwriting all data, or starting a new data file, which you now get to merge manually with the one it ignored, for instance) ... in fact unix C tools are still (and, imho, justifiably) famous for their "nuke the whole world upon encountering a slight syntax issue" behaviors. Besides, the Go authors' own tools usually crash (log.Fatalf), but without stacktrace or unwind, on 90% of errors. That's, of course, even worse than exceptions crashing out of the program in several ways: 1) You have no idea what happened. We're back to grepping the source code for the last string it printed and praying you find something. Stacktraces ! GIVE ME BACK MY STACKTRACES. 2) Cleanup does not happen (!!!!!) with log.Fatalf. I repeat: NO CLEANUP WILL HAPPEN WHEN CALLING log.Fatalf. DO NOT USE log.Fatalf if your program has done anything at all !!!!!!!! The go authors themselves, especially should have gone through the exercise of, at EVERY error check, figure out what needs unwinding (file closing, ...) and then doing the same at higher levels of the stack as well. Needless to say, NOBODY, not even Rob Pike himself, has done that. As far as I can tell, not even once. 3) we all know how these bugs get fixed. By changing "crash out" to ignore. And frankly, given point 2, I will actually call it an improvement.