add guidelines for choosing panics or error results (#6958)

* add guidelines for choosing panics or error results

* add note to clarify that checking invalidity of user input is the key point

* apply reviewer suggestions

Co-authored-by: Andrew Lamb <[email protected]>

* remove redundant word

* fix markdown format

---------

Co-authored-by: jp0317 <[email protected]>
Co-authored-by: Andrew Lamb <[email protected]>

README.md

@@ -90,6 +90,16 @@ Planned Release Schedule
 | Dec 2024         | `0.11.2` | Minor, NO breaking API changes          |
 | Feb 2025         | `0.12.0` | Major, potentially breaking API changes |
 
+### Guidelines for `panic` vs `Result`
+
+In general, use panics for bad states that are unreachable, unrecoverable or harmful.
+For those caused by invalid user input, however, we prefer to report that invalidity
+gracefully as an error result instead of panicking. In general, invalid input should result
+in an `Error` as soon as possible. It _is_ ok for code paths after validation to assume
+validation has already occurred and panic if not. See [this ticket] for more nuances.
+
+[this ticket]: https://github.com/apache/arrow-rs/issues/6737
+
 ### Deprecation Guidelines
 
 Minor releases may deprecate, but not remove APIs. Deprecating APIs allows