| This is a pretty disingenuous criticism. > The fact that the stdlib HTTP utils in Go recover from panics in handlers and provide no way of changing this It's comically easy to just wrap the root handler, catch panics yourself, and explode. > You need to provide your own error handling middleware (of which several exist). And you need to provide your own handlers anyways, which seems reasonable to me, unless you're against writing code? > A beginner needs to be very careful and read the docs to catch e.g. this line: Yes you need to read the docs to understand what a function does. This does not require being very careful where I'm from. > Also, the fact that Go kind of blesses the use of panics internally in a library ... makes for even more brittle software, as predicting what state a control flow interruption like panic through a call stack leaves your data in can be challenging and require great care to avoid invariants being violated. They make this pretty clear, that you shouldn't leak the panic, in which case it's just an implementation detail. If your library is brittle, that's on the implementer. You don't have to use panics for control flow. It's just something you can do. A tool. Sure, maybe it's sharp. > I don't like brittle stuff like encouraging panic-like control flow for non-exceptional situations I've never seen anything remotely encouraging use of panic for control flow. The blog post even states it's uncommon and unusual. I don't know how you interpreted that blog post, which reads to me as "here's how defer works", to being "you should use panic for control flow whenever possible." |
> It's comically easy to just wrap the root handler, catch panics yourself, and explode. > And you need to provide your own handlers anyways, which seems reasonable to me, unless you're against writing code? > Yes you need to read the docs to understand what a function does. This does not require being very careful where I'm from.
Yes, it's "comically" easy to do so if you know that you need to do it. I do it. I didn't say it was hard to do. But Go prides itself on being beginner friendly, having consistent behaviors and not having many ways of doing the same thing. The main function doesn't automatically recover from panics. Spawned goroutines don't automatically recover from panics. I feel like it wouldn't be outrageous to consider this an expected behavior for someone writing Go code, as very few libraries to my knowledge recover panics they didn't start themselves. The behavior of the stdlib HTTP utils diverge from that expected behavior. I think there are tons of developers in every language who don't necessarily scour the docs but assume consistency with some behaviors that seem basic and logical. Again, opinion, if that wasn't clear.
> They make this pretty clear, that you shouldn't leak the panic, in which case it's just an implementation detail. If your library is brittle, that's on the implementer. You don't have to use panics for control flow. It's just something you can do. A tool. Sure, maybe it's sharp.
Yes, they make it clear how it should be used if it is used, and I didn't claim otherwise. I also didn't claim that leaking it was the problem, but instead that maintaining invariants in the data of the library using the mechanism can be a hard thing to do, and whenever something is hard to do right it can contribute to brittle software.
> I've never seen anything remotely encouraging use of panic for control flow. The blog post even states it's uncommon and unusual. I don't know how you interpreted that blog post, which reads to me as "here's how defer works", to being "you should use panic for control flow whenever possible."
Yes, I will meet you half way here. :) This particular blog post doesn't encourage it, and at the moment I can't other any of the other places I've seen it. The blog post gives an example of Go stdlib using it, and then describes how to use it in a library if it is used. My personal preference would be to offer more caution or perhaps even discouraging in that blog post, but again that is personal opinion.
Summing up, I think Go is a language that both strives to be and is beginner friendly. Diverging from consistency in basic behaviors in the stdlib is not great, sharp tools not labeled as such is not great, etc, in my opinion. I know we don't agree and that's perfectly fine. I appreciate your reply. But I'm not trying to be disingenuous.