Is function parameter validation using errors a good pattern in Go? -

is parameter validation using error return codes considered practice ? mean should use errors vs panics (are there guidelines?).

for instance:

• is checking non-nil + returning error if nil practice ?
• or checking correct integer ranges etc.

i imagine using errors make go feel c-ish , pretty bad. panics alternative in situations ?

or should gopher use python/ruby/js-approach "just let fail" ?

i'm bit confused because panics real "errors" in understanding. using errors time bad.

and if return error code: if passes wrong parameter function ignores errors codes ? -> nothing! panics nice situations in language error codes used on panics not clear.

"escaping" panics¹ in go (i mean, might produced functions comprising public api of package) deal errors programmers do. so, if function gets pointer object, , can't nil (say, indicate value missing) go on , dereference pointer make runtime panic if happens nil. if function expects integer must in range, panic if it's not in range — because in correct program values might passed function are in range, , if don't either programmer failed obey api or did not sanitize value acquired outside which, again, not fault.

on other hand, problems failure open file or pefrorm other action function supposed perform when called correctly should not cause panics , function should return appropriate error instead.

note recommendation explicit checking null parameters in functions of public apis in .net , java code has different goal of making such kinds of errors sort-of more readable. since 99% of .net , java code lets exceptions propagate top level (and displayed or may logged) it's replacing 1 (generated runtime) exception another. might make errors more obvious—the execution fails in api function, not somewhere deeper down call stack—but adds unnecessary cruft these api functions. yes, opinionated subjective opinion is: let crash ok in go—you'll descriptive stack trace.

tl;dr

with regard processing of run-time problems,

• panics programming errors;
• returning errors problems carrying out intended tasks of functions.

---

¹ legitimate use panics quick "cold-path" returning deep recursive processing/computation; in case panic should caught , processed package, , corresponding public api functions should return errors. see this , this more info.