Here's a trivial example:
if type(length) != int: length = 16
as opposed to:
try: len_mod = (length + 33) / 32 + 1 except TypeError: #recover here somehow, over-ride input? len_mod = (16 + 33) / 32 + 1
I don't need an authoritative answer, but some opinion on this approach would be fine.
Some info about the surrounding code, as it stands now:
- I don't expect anything but an
length. I will never expect anything else.
- There's no purpose in showing an error message (this is a stand-alone method)
- There's no harm in suppressing the error (for now, nothing else uses this method)
With that information, is it still alright to hijack (albeit, bad) user input and suppress the resulting error by replacing it with what would have been the default value in the function?
I ask because I've never read anyone else's code where this happens, and I have wondered if there was a reason for that I'm missing.
Feel free to invent some cases where I might regret this decision, or any other points you'd like to highlight for the sake of example.
Another angle: my goal is to make a useful, single serving website, quite similar to tinyurl. I tested their site using a similar bit of invalid data, and it didn't report anything back to me. It just let me be stupid:
They didn't check if my site matched a regex for syntactically valid domains, they didn't even bother mentioning that my original link was 6 characters shorter than what they gave back. I think this is a good thing, from a user's perspective. Why tell me what the site can and can't do?
I understand that this code, being for a stand-alone, single-serving application, may or may not be subject to some of the same rules as other, more modular functions are. Given the circumstances, how do I write my code to suffer fools lightly, and still be durable and extendable? So far, I'm quite happy with the short, direct
try:except block acting as a guardian.