To add to this: In an ideal programming language misusing an API should be preventable with static analysis. But that becomes very difficult quickly. E.g. forcing integers in a certain range is difficult to represent with types. Panics are a suboptimal solution, but probably the best.
April 27, 2025 at 7:22 PM
To add to this: In an ideal programming language misusing an API should be preventable with static analysis. But that becomes very difficult quickly. E.g. forcing integers in a certain range is difficult to represent with types. Panics are a suboptimal solution, but probably the best.
I disagree with "thou shalt not panic". Panicking is useful to catch developer errors early. Panics should optimally only ever happen while developing and prevent developers from misusing APIs. This answer explains it pretty well: stackoverflow.com/a/22865084/5...
Is function parameter validation using errors a good pattern in Go?
Is parameter validation using error return codes considered good practice ? I mean where should somebody use errors vs panics (are there any guidelines?).
For instance:
Is checking for non-nil +
stackoverflow.com
April 27, 2025 at 7:18 PM
I disagree with "thou shalt not panic". Panicking is useful to catch developer errors early. Panics should optimally only ever happen while developing and prevent developers from misusing APIs. This answer explains it pretty well: stackoverflow.com/a/22865084/5...