On Fri, Oct 21, 2022 at 5:16 PM Robert Engels <reng...@ix.netcom.com> wrote:
> Unchecked exceptions in Java denote programming errors or critical
> unrecoverable errors.
>
Yes, that's exactly what I'm saying. This is what panics are used for in
Go; if you have an error that is recoverable you ought to be returning an
error, not panicking.
> If these are being trapped/handled it is indicative of a system with
> design errors.
>
> (That being said, some programming errors can be ignored/handled at the
> request level - indicating that the chance any particular request triggers
> the bug is low).
>
I don't think handling panics is necessarily indicative of design errors,
but I do agree that it's not something that should be done lightly. A big
part of why Go has largely succeeded in getting people to actually use
checked errors is that recovering from a panic is just complex enough that
you wouldn't attempt it without a really good reason (compared to Java,
where "recovering" from an unchecked exception by ignoring it or tossing in
an empty catch {} block is trivial to write, so people do it all the time,
unfortunately).
But t.Fatal is another panic-like operator, in that it reroutes control
flow without any error handling, and I've seen projects using it as such,
writing `f(t, g(t), h(t))` where each function calls t.Fatal() if anything
goes wrong, instead of having each function return a value and an error.
That's what the Ondatra example I linked was demonstrating - real code in
the wild using t.Fatal as a way to have "unchecked exceptions".
Dan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAAViQtj%3Dayhoi0XH%2BtDeRJAtgfE6wt81hMszAhG3UiSPLUndJg%40mail.gmail.com.
