|Keep It Simple, Stupid|
In my eyes, the number argument is required and not passing it should throw an exception.
But you are still dodging my question.
The point is, what difference would it make to how you handle the situation -- in your calling code -- whereby your code passes a non-numeric value to be numerically formatted.
If instead of concentrating upon some wholly artificial and academic value judgement of what (in your opinion), the module should or should not do, and instead think about what action your code would take when this situation arises, then you'd probably arrive at the conclusion that there are only two possibilities:
If the values are coming in from an unreliable (external) source, then you should be checking that they comply with your input criteria at source, and rejecting them if they fail to so comply. If you have done that, then an additional check at some later point when you are using them -- for example, inside a round() function -- are completely redundant.
If however, the values are being generated internally by your code, then it again falls to you to ensure that your code cannot generate non-numeric values where numeric values are required. Expecting a library routine to check your values for you is ridiculous.
The bottom line is that if you call a library routine to round() a numeric value, it falls to you to ensure that you only pass it numeric values. Expecting every other user of that module to bear the cost of the redundant check, just so you can avoid performing that check when required, is selfish. You (should) know where and when (in your code) it is necessary to validate values.
Look up design by contract.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.