Provide helpful message when incorrectly forcing balance to below ED

[gilescope]

Had to debug through some code to find out what was going wrong. This will make it obvious for the next person writing a new test and wondering why setting the balance doesn't work.

I've run all the tests in debug mode to make sure they currently all pass:

cargo nextest run --workspace --locked --verbose --features runtime-benchmarks,try-runtime,experimental
...
Summary [ 702.876s] 5452 tests run: 5452 passed (97 slow), 25 skipped

[gilescope]

Here's another example where we use debug_asserts so I think this is fair game: https://github.com/paritytech/substrate/blob/19eb56a3fc51140b269e339ecb7e9a4a378c26ff/frame/support/src/traits/tokens/fungibles/regular.rs#L549C4-L549C60

[liamaharon]

Looks fine.

However I'm not sure if this is correct usage of debug_assert!, which I understand is supposed to make assertions that should never fail - failure means there is some fundamental breakage in the way the program is supposed to execute.

Is there an alternative that maybe logs instead of asserts?

not sure actually if this is correct use of debug_assert!

[bkchr]

This should be an update of the docs and not more. The function doesn't prevent users to pass values that are smaller than ED. I also don't see any reason why we should prevent this and then having a debug_assert!.

[gilescope]

Thanks for the feedback. I've switched it to log an error. I wanted there to be some warning/error in the output when someone runs cargo test. If the log message is just a warning then it's not visible from the command output, so there would be little point. (Could we configure warnings to be displayed when tests are run?)

[liamaharon]

I agree with Basti that this should be a docs change.

Fundamentally, the purpose of this pr is to clarify edge case behavior to the developer. Explanation of code behavior is not something that should happen during runtime, but happen when the devs read the docs.

A good developer will read the docs of a method if they encounter behaviour they do not expect while using it, so I don't think having this log provides additional value compared to just adding that.

Moreover, the log is quite verbose. I'd be concerned about setting precedent that it's OK to start documenting edge case behavior with logs throughout the codebase when a doc comment would suffice.