> When checking preconditions, make sure the panic message relates to the documented precondition, perhaps by adding a custom message. For example,
> `assert!(!xs.is_empty(), "expected parameter 'xs' to be non-empty")`.
This panics with
> thread 'main' panicked at 'expected parameter 'xs' to be non-empty', src/main.rs:79:5
Without the custom message it's
> thread 'main' panicked at 'assertion failed: !xs.is_empty()', src/main.rs:79:5
Given that panics should be for bugs, i.e. interpreted by developers, I'd say the second message is clear enough and a custom message just adds noise in the source code.
I don't disagree. Definitely depends on how opaque the assertion test is. In this case, yeah, probably don't need a message. Pithy illustrative examples are hard.
> `assert!(!xs.is_empty(), "expected parameter 'xs' to be non-empty")`.
This panics with
> thread 'main' panicked at 'expected parameter 'xs' to be non-empty', src/main.rs:79:5
Without the custom message it's
> thread 'main' panicked at 'assertion failed: !xs.is_empty()', src/main.rs:79:5
Given that panics should be for bugs, i.e. interpreted by developers, I'd say the second message is clear enough and a custom message just adds noise in the source code.