|
> the only problem with exceptions is that developers don't use them, or don't use them properly, or aren't forced to use them Well, that's enough of a rationale for trying some other mechanism, isn't it? > Exceptions in Ruby, Python, Java, C#, etc. are a tried-and-true paradigm for handling unexpected code paths the problem is, most errors aren't "unexpected code paths". Trying to open a file whose name is provided by the user, for instance, can fail for several reasons: file does not exist, permission is denied, file is busy, file content is invalid, etc. None of these situations is "unexpected", they are all part of the task being solved. Now, accessing the first element of an empty list, dereferencing a nil pointer, dealing with a value that has an illegal state, facing a bus error or a stack overflow? Now that sucks, that is unexpected and it should be dealt with some special mechanism. That's where exceptions really shine (and go has panic/recover for those, ahem, exceptional circumstances). |