On Tue, Apr 25, 2017 at 5:06 AM, Kevin Conway <kevinjacobcon...@gmail.com> wrote:
> In this example we're considering panic as a mechanism of preventing > otherwise avoidable code bugs. What happens when the same code begins > silencing panics and continuing on? Do we add a new level of panic that > overcomes the normal recovery method? The fundamental assertion being made > by panic advocates is that you know better than I when my program should > end and you want some mechanism to enforce that opinion on me. > > I'll argue that sticking to idiomatic errors returned by function calls > combined with static analysis tools, like errcheck, are sufficient in > solving for all scenarios where panic might otherwise be used to signal an > error state. > Array OOB? Nil-dereference? Division by zero? Why not add an error value to every slice and arithmetic operation, because the programmer knows best when to abort their program. This is obviously absurd, but it does strike home; error returns are changing the ergonomics of an API, but more than that, whatever your theory on panics and errors is, it must also account for why, apparently, some panics are okay after all. There is nothing *fundamentally* different between a panic created by the runtime/language and a panic created by a library author. In that way, at least "if you detect a clear code bug, panic" is at least consistent. > If you want to use panic internally within an API that's completely > acceptable so long as that panic is never exposed beyond the API boundary. > To quote the golang blog on the subject: > > The convention in the Go libraries is that even when a package uses panic > internally, its external API still presents explicit error return values. > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
