With exceptions you can

1. Set exception breakpoints.

2. Have real stack traces.

3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world.

Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because

1. You are making a network call or OS interactions every 2 lines which can err

2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments.

3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling.

I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.

I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.

What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.

panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.

But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho).

edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430

Debatable. It correctly identifies that an exception is data structure (object), but claims that Go doesn't create one, even though it clearly does as it will plain print the contents of that "object" if you don't catch the exception. I will grant you that it doesn't pass the exception by value, which is different than in some other languages, but that's an implementation detail.

Furthermore it seems to claim that Go using basic stack unwinding precludes it from it having exception handlers, but that's an implementation detail too. Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?

Funnily enough, it is Javascript, not Go, that doesn't create the exception object automatically. You have to manually initialize the poorly named Error type manually (`new Error(...)`) in your code in order to create an exception. But that also is just an implementation detail.

> But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure.

What's typical? We do see some more advanced exception handling systems out there, but Javascript's is just as simple as Go's (in some cases even simpler), yet nobody that I have ever met claims that Javascript doesn't have exceptions/exception handlers. The one thing Javascript does have that Go doesn't is try/throw/catch syntax, but, of course, you can easily emulate that if you're really hung up on trivial appearances: https://go.dev/play/p/aXS5WEziLzS Exception handlers aren't defined by any particular syntax. That, again, is an implementation detail. Go does have syntax for exception handling even if its syntax is unique.

> Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?

No, I wouldn't, so re: that - fair point;

For me, Go's error+panic lack of propagation + lack of exception type hierarchy are what stick out and seem vastly different to "typical"; and this does impact development, especially propagation mechanism / lack thereof. But I also haven't written lots of Go code, and could be possibly lacking experience, and am just looking from "typical" language lens (Java (not JS), Python, from my PoV)?

To circumvent this, a lot of exception languages are written in a more defensive style.

Here is some sample Java code to demonstrate:

    > try {
    >     FileReader reader = new FileReader("file.txt");
    >     // Use 'reader' here.
    > } catch (FileNotFoundException e) {
    >     // ...
    > }

    > To circumvent this, a lot of exception languages are written in a more defensive style.

    > brittle in the case of C#