So Go has panics and they are _just like exceptions_ in Python? Because to accuse the writer of being "flat out false" these have to be exactly the same and he as to be ignorant to not see the obvious.
Let's say you have some step in your function and you might raise an exception. In Python you'd surround it with try...catch
try:
dosomething()
catch SomeException:
handle_exception()
> there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation
ignorance? have you read the basic Python documentation, sounds like you haven't
No, they don't. Because the claim that I called flat out false was this
>> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way.
So, no, Go's exception mechanism doesn't have to be "just like Pythons" for this to be flat-out false. What it does need to be is anything that allows propagating errors up a call chain without an if at every function call along the way. Which panic/defer/recover is.
> And don't crate a new function that that is not what Python does.
Even if I did accept your "must work like Python" standard (which is, itself, wrong because its not necessary for the statement at issue to be flat-out false), what's the substantive difference between an immediately-called anonymous function and a block?
Sure, you could legitimately complain that the example would be more verbose in Go, but that's not the complaint OP made. (The most direct translation of your example would look something like this in Go -- though in practice you wouldn't really do this this way):
func() {
defer func() {
r = recover()
if e, ok := r.(SomeException); ok {
handle_exception()
} else {
panic(e)
}
}
dosomething()
}()The statement that Go has "no exceptions", or that for deep error handling in your own code you have to handle errors at each level is false. And, fine, you didn't learn anything about it because maybe you saw sample code showing how you need to deal with the public API of common libraries because of the Go convention that panics aren't exposed across public APIs. And if all you said was that, it'd be fine -- but you went beyond that and said things that weren't true and which people who haven't learned the language might not realize were statements from ignorance rather than experience, and might turn them off of the language where they wouldn't be turned off if they knew the truth, because if they were true, they'd be real and deep problems with the language design.
Choosing to remain ignorant about Go because it doesn't seem like its worth your time to learn is fine. Making up stories about why you don't like Go that aren't grounded in anything real is not.
TL;DR: if you choose to be ignorant, you don't get to pretend to be an authority.
I'm not worried about people who have learned Go getting turned off by inaccurate comments about it not having exceptions, I'm concerned about people who might read your piece before learning much on their own. If people believe your claim that Go has no exceptions and that multi-level error handling in your own code has to be done the way you described, that could turn people off of Go whether they like the standard library or not (and before they even decide whether to try it at all.)
This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality.
It is a go convention that library code doesn't let panics escape to the calling code, so if you are going to use panics in your own code, to follow the convention you should be recovering from them somewhere in the call chain that you control rather than letting them escape across the public API of your code. But that's it, they exist, and can be used. So, while there may be some ground to complain that when calling the standard library you have to handle error returns rather than catching exceptions (equivalently, "recovering from panics") -- though, IMO, there is a good reason for this design choice -- there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation -- to say that you don't have exceptions that you can use within your own code and that you have to to error-return handling at every level in your own code to deal with error propagation. If you make that complaint, it is clear you don't know what you are talking about.