[luriel]

> no exceptions

This is one of my favorite features of Go. Exceptions are a horrible mess in every language I have seen that has them. They make following control flow basically impossible. They are equivalent to COME FROM.

Go's multiple returns and defer/panic/recover are a much cleaner way to handle errors, not perfect, but way superior to exceptions.

> Go ignored parametric polymorphism (aka generics)

Go didn't ignore parametric polymorphism, Go already has features (interfaces and slices/maps) that provide most of what people use generics for. Go might even get generics some day if a good design for them is found. But the people using Go every day don't miss generics, and that is because the language itself already provides what people needs.

Also note that C lacks both exceptions and generics, and many people still consider it the best language around to build many kinds of systems.

[ootachi]

Go has exceptions. They are called panic/recover.

This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.

Additionally, people get around the lack of generics in C with macros. Go doesn't have those.

[luriel]

If panic/recover is the same as exceptions, why does everyone whine about the lack of exceptions?

The fact is that while in theory panic/recover are mostly equivalent to exceptions, in practice they are very, very different. Panic is only used in truly extreme situations (like running out of memory) or programmer errors, and you can pretty much write code ignoring it.

Most programs at most will need to call recover() once. Compare this with how exceptions are used in most languages where they are a fundamental aspect of a library's API.

Also the way defer() reliably and cleanly handles cleanup is much more pleasant than exception and 'finally'.

As for C macros, good C programmers have known for a long time that they are best avoided as much as possible.

[ootachi]

Because panic/recover are bad exceptions (recover can't specify the types of the exceptions it wants to recover from), and the libraries don't use them. Having to check errors is annoying since most of the time you want to bubble the error up to your caller. This is exactly what exceptions (or the error monad) do for you. In Go you have to do it manually.

Anyway, Go does have exceptions. It just doesn't make much use of them. Seems a shame to not use a useful feature, but oh well.

defer is not reliable if you forget to call it. RAII is much more foolproof than defer in this way. You can forget to call defer, but you can't easily forget to call the destructor.

[batista]

>* Having to check errors is annoying since most of the time you want to bubble the error up to your caller.*

No, most of the time I don't.

[ootachi]

What do you do then?

If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls.

If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call.

If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.

[batista]

>If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls. If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call. If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.

How about locally handling the problem --which could be some non-issue-- and continue without the OVERHEAD of an Exception?

How about now using the verbose and convoluted try-catch-finally idiom for common and not at all exceptional error conditions?

How about THINKING about the error handling, instead of blindly catching "many different types of exceptions in one try-catch block and re-throw a different exception", which we've known for Java to result in a mess...

How about avoiding the exception stack penalty that happens when you "group multiple related calls into one try-catch block and avoid having to check at the site of each and every call" to merely log errors?

[batista]

>Go has exceptions. They are called panic/recover. This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.

He might ignore the similarity of panic/recover with Exceptions, but you also ignore:

panic/recover is not used for 99% of exception control in Go. We just check the out-of-band error code and act accordingly.

Panic/Recover is only used for TRULY EXCEPTIONAL situations.

Wish we could say the same for, say, Java's exceptions.

[ootachi]

Odd that you say that, because the language that's most similar to Go here is Java, with its checked exceptions. The same reasoning that led to Go's error codes (that you should always handle your errors) led to checked exceptions. The fact that people generally think checked exceptions are a bad idea is a point against Go, not in favor of it.

Checked exceptions are superior to Go's error return codes anyway, since they make it easier to bubble your errors up to your caller.