@katrinafyi

In a vacuum, I would lean towards making it an error with an option to bypass the error. I don't think it's too much disruption, and most people would probably appreciate the obvious error. But either way is much more helpful than silent with no message.

I was debating this myself! Initially, I tried to be conservative, but after thinking about it some more, let's be bold and the right thing. A hard error will definitely prevent users from accidentally checking an empty/error page and assuming everything is fine. Let me update this PR to return an error instead of a warning. What do you think about deferring the introduction the bypass-flag until someone explicitly asks for it? Too pragmatic?

I think I'm just very cautious when it comes to changing defaults and errors, after past experience 😅

Being cautious is generally the wise approach, yes, but in this case, my goal is to avoid increasing the number of CLI flags we have to maintain. There's a chance we will have to add another flag, but my hope is that people just treat it as an actual bugfix and accept it as the expected behavior when providing invalid inputs. We'll have to see. :^)

The actual change is pretty simple, but we went through a few iterations to find the right approach. I'm still not 100% satisfied, since the new match arm returns a sentinel value. I've added a TODO to refactor that:

// This `details()` method never gets called for incorrect CLI
// inputs, so whatever we put here, it won't be shown to the user.
//
// This returns an empty string as a sentinel value because it's handled as a
// fatal application error rather than a link-level error.
//
// TODO: In the future, we should return an Option<String> or separate
// application errors from library errors.
ErrorKind::ReadInputUrlStatusCode(_) => String::new(),