5 ms·

yawn Yet one more rant completely missing the point and whining about the lack of exceptions (which at least as implemented on most languages most sensible and

by uriel 17y ago

yawn Yet one more rant completely missing the point and whining about the lack of exceptions (which at least as implemented on most languages most sensible and experienced people agree foment bad error handling practices, so the current Go approach is superior) and generics (still unclear if they make any sense given Go's interface system, which the author completely ignores.) And reading the rest of the gripes, the author clearly had zero interest in learning the language. > (Yes, that is a statement you see between "if" and the test. No, it serves no real purpose beyond obfuscation.) Way to show you have not learned anything about the language or even tried to write even a program a dozen lines long!

barrkel 17y ago
Fundamentally disagree with you on exceptions. Exceptions as implemented in e.g. Delphi or .NET work very well. In C++ the complexity of exception handling is deeply exacerbated by things like copy constructors - the bias in the language towards (what I call) value-oriented programming, rather than object orientation - and in Java exceptions are hobbled by the misguided notion that exceptions should be handled nearer the point of the throw rather than far away, in the relevant main loop of the app; hence the requirement to trace through annotations throughout the call graph from low-level throwing code to high-level catching loops, or basically avoid the bad design with RuntimeException.
- jgrahamc 17y ago
  I agree with the person you are disagreeing with, in this case. Go is being touted as a systems programming language. My experience of very low level programming is that you want to know exactly what's happening, and especially when things go wrong. And you want to know what's gone wrong right at the point of it going wrong. Exceptions are the wrong technique for this form of programming. When doing systems work you are spending a lot of time dealing with error situations and hence the handle the error and pass up an error code form is appropriate.
  - sreque 17y ago
    Even in Kernel programming, exceptions are useful. If you read http://www.kernel.org/pub/linux/docs/lkml/#s15-5 http://www.kernel.org/pub/linux/docs/lkml/#s15-5, you'll see that goto's are used to reduce code duplication for error handling, which is essentially just a poor man's exception. More sophisticated exception handling in C can and has been done with longjmp as well.
    - deleted 17y ago
      [deleted]
    - uriel 17y ago
      Go has goto. Unlike goto as used in the linux kernel, exceptions will jump up the call stack god knows where. And in essence exceptions are not goto, but camefrom.
      - barrkel 17y ago
        Exceptions jump to the declared handler - i.e. the right place. I remain convinced that far too many people have gotten wrong ideas about exceptions from the bastardized implementations in C++ and Java.
  - barrkel 17y ago
    "Systems programming language" is a loaded term, IMO. Many people have used C - probably the canonical systems programming language - inappropriately for applications where better languages would have been more suited. We've paid the price in insecurity, buffer overflows, memory errors, etc. many times over. I think you need to more clearly define what you mean by it. You can't mean very low level programming, since that is a very small fraction of all programming - and probably not the best domain of a general purpose programming language. As I mentioned in another comment in this thread, I see exceptions as exactly equivalent to a rigorous approach to error codes. I also note with interest that you describe the form as "handle the error and pass up an error code". This reads to me as a contradiction in terms. While the error code is still propagating, the error has not been handled. Some intermediate cleanup has perhaps been done, but normal code execution has not yet resumed. Moreover, exceptions have mechanically checkable formalisms for these phases of error handling.
- shin_lao 17y ago
  One of the reasons why exceptions are difficult to use well is because of the guarantee you offer when you raise one. What happens when your function raises an exception? Rollback? Undefined? That's the real difficulty. More information here: http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.aspx http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161....
  - barrkel 17y ago
    Guarantees in the case of error is an orthogonal issue. The same problem exists for error codes. In fact, I see exceptions as a formalization of an extremely rigorous approach to error codes, where in the case of a failure the error codes is immediately propagated to the callers after local cleanup.
btilly 17y ago
The best thread on the Go list about exceptions IMO has been http://groups.google.com/group/golang-nuts/browse_thread/thread/6f22b6aa6a6a3044 http://groups.google.com/group/golang-nuts/browse_thread/thr.... In particular see http://groups.google.com/group/golang-nuts/browse_thread/thread/6f22b6aa6a6a3044#msg_118bda55292d05e3 http://groups.google.com/group/golang-nuts/browse_thread/thr... where I tried to explain the strengths and limitations of exceptions. In particular you'll find an answer to your silly claim that exceptions are something that most sensible and experienced people agree foment bad error handling practices AND you'll find an explanation of why they are reasonable to omit from Go.

by uriel 17y ago

barrkel 17y ago

Fundamentally disagree with you on exceptions. Exceptions as implemented in e.g. Delphi or .NET work very well. In C++ the complexity of exception handling is deeply exacerbated by things like copy constructors - the bias in the language towards (what I call) value-oriented programming, rather than object orientation - and in Java exceptions are hobbled by the misguided notion that exceptions should be handled nearer the point of the throw rather than far away, in the relevant main loop of the app; hence the requirement to trace through annotations throughout the call graph from low-level throwing code to high-level catching loops, or basically avoid the bad design with RuntimeException.

jgrahamc 17y ago
I agree with the person you are disagreeing with, in this case. Go is being touted as a systems programming language. My experience of very low level programming is that you want to know exactly what's happening, and especially when things go wrong. And you want to know what's gone wrong right at the point of it going wrong. Exceptions are the wrong technique for this form of programming. When doing systems work you are spending a lot of time dealing with error situations and hence the handle the error and pass up an error code form is appropriate.
- sreque 17y ago
  Even in Kernel programming, exceptions are useful. If you read http://www.kernel.org/pub/linux/docs/lkml/#s15-5 http://www.kernel.org/pub/linux/docs/lkml/#s15-5, you'll see that goto's are used to reduce code duplication for error handling, which is essentially just a poor man's exception. More sophisticated exception handling in C can and has been done with longjmp as well.
  - deleted 17y ago
    [deleted]
  - uriel 17y ago
    Go has goto. Unlike goto as used in the linux kernel, exceptions will jump up the call stack god knows where. And in essence exceptions are not goto, but camefrom.
    - barrkel 17y ago
      Exceptions jump to the declared handler - i.e. the right place. I remain convinced that far too many people have gotten wrong ideas about exceptions from the bastardized implementations in C++ and Java.
- barrkel 17y ago
  "Systems programming language" is a loaded term, IMO. Many people have used C - probably the canonical systems programming language - inappropriately for applications where better languages would have been more suited. We've paid the price in insecurity, buffer overflows, memory errors, etc. many times over. I think you need to more clearly define what you mean by it. You can't mean very low level programming, since that is a very small fraction of all programming - and probably not the best domain of a general purpose programming language. As I mentioned in another comment in this thread, I see exceptions as exactly equivalent to a rigorous approach to error codes. I also note with interest that you describe the form as "handle the error and pass up an error code". This reads to me as a contradiction in terms. While the error code is still propagating, the error has not been handled. Some intermediate cleanup has perhaps been done, but normal code execution has not yet resumed. Moreover, exceptions have mechanically checkable formalisms for these phases of error handling.
shin_lao 17y ago
One of the reasons why exceptions are difficult to use well is because of the guarantee you offer when you raise one. What happens when your function raises an exception? Rollback? Undefined? That's the real difficulty. More information here: http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.aspx http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161....
- barrkel 17y ago
  Guarantees in the case of error is an orthogonal issue. The same problem exists for error codes. In fact, I see exceptions as a formalization of an extremely rigorous approach to error codes, where in the case of a failure the error codes is immediately propagated to the callers after local cleanup.

btilly 17y ago

The best thread on the Go list about exceptions IMO has been http://groups.google.com/group/golang-nuts/browse_thread/thread/6f22b6aa6a6a3044 http://groups.google.com/group/golang-nuts/browse_thread/thr.... In particular see http://groups.google.com/group/golang-nuts/browse_thread/thread/6f22b6aa6a6a3044#msg_118bda55292d05e3 http://groups.google.com/group/golang-nuts/browse_thread/thr... where I tried to explain the strengths and limitations of exceptions. In particular you'll find an answer to your silly claim that exceptions are something that most sensible and experienced people agree foment bad error handling practices AND you'll find an explanation of why they are reasonable to omit from Go.