Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

(2019), but still good-ish advice. The pattern works like a charm in modern C# as well, and has nice space-saving effects too by allowing you to omit the explicit variable declaration:

    if(!Whatever.TryParse<Thingy>(input, out var output)) output = some-sane-default;

or:

    if(!Whatever.TryParse<Thingy>(input, out var output)) throw new ApplicationException($"Not a valid Thingy: {input}");

Protip: don't do the latter in your kernel-mode driver.

View on HN

Protip: Don't do either. And definitely don't do the first.

Explicit is always better than implicit defaults that get used instead when you give it a wrong value that you think is correct.

What you should do is throw your hands up early, fail to parse, and have a very clearly defined process and protocol to handle files that couldn't be loaded. It'll force you to ask yourself very difficult questions that aren't covered by either of the two options you posted.

The real failure in the recent Crowdstrike kernel-mode driver failing to parse some def/config file is that the dev/product owner/BA didn't ask "what happens if we try load a file that's invalid?"

> (2019), but still good-ish advice

Why only "good-ish"? And how does it relate to the year the article was published? Surely you are implying that the advice in the article would be more authoritative if it were published earlier than 2019, right?

Aversion to truth seems more fashionable now than in 2019.

Please don't do the first. Handle the bad cases. "sane default" fallback should be extremely rare.

Explicit > Implicit

As always, it depends.

E.g. you don't want to refuse to open a document just because ten pages in there is a footnote that is somehow malformed.

Depending on the possible consequences, GIGO is much better for usability. Ideally you'd warn the user that something unexpected has occured and he should manually check the result but whenever you are handling external data where malformed input cannot be avoided then erroring early will only make your software less useful to the user who more often than not cannot do anything about the error but can manually correct the fallback if you got it wrong.

if(!Whatever.TryParse<Thingy>(input, out var output)) output = some-sane-default;

I absolutely hate that. IMO you should handle the error of an invalid input outside of the function to parse. F# makes that easy.

    type Whatever =
    static member create input =
      match input with
      | ValidWhatever x -> Some x
      | _ -> None

    match Whatever.create input with
    | Some x -> //process the parsed data
    | None -> //handle it not being parsed well

Or you could also use Option.map/Option.bind to build a pipeline to handle chained operations in an ergonomic manner.

With this, you can only instantiate any instances through the create method with parses the input.

Altough, you probably want to use a result rather than option, but I digress.

> 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.

If 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.

Reply on news.ycombinator.com