3 ms·
> if(!Whatever.TryParse<Thingy>(input, out var output)) output = some-sane-default; I can't think of many (probably any) situations where I'd want to find that
by nucleardog 2y ago
> if(!Whatever.TryParse<Thingy>(input, out var output)) output = some-sane-default;
I can't think of many (probably any) situations where I'd want to find that.
If _no_ input is provided (i.e., the parameter is optional), sure, using a sane default makes sense.
If _invalid_ input is provided, for the love of god please don't pretend like nothing's wrong.
If someone walks into a florist and asks for a coffee, the correct answer is not for them to be handed a rose. They're going to cut their mouth all up when they try and drink it.
Your method/module/program does not have an output defined for that set of inputs. Make that obvious rather than just doing wrong or non-obvious things in a way that quickly makes your program almost impossible to reason about. Do yourself a favour and clearly raise the issue and leave yourself a stack trace pointing directly to the issue instead of setting yourself up for the vague bug about incorrect behaviour when someone catches this in a few months.
- account42 2y agoIf someone reserves a hotel room it makes sense to reserver any room if the desired selection is not valid. Of course you should notify the user of the error but preventing the process from continuing is often unhelpful. Similarly when converting a file you often should not abort the operation just because there is some minor detail in the original that you can't parse. The user is generally not in a position where they can do anything about such an error but they can often fix up the partially correct result. Of course you shouldn't do the fallback silently and at least notify the user that there was a problem.