An Exception should be exactly that: an Exception, not an expected control flow for normal situations. Yes, I get that these are not all that different in practice, but then again, `throw` isn't all that different than `goto` either, and `catch(err)` definitely implies something other than "if(url)", and covers a much more ambiguous set of scenarios on its own.

Okay so I guess I'm also a guy who can't handle try catching

Clearly he can handle it given that he mentioned try-catch and the cons of using that approach (cant use const, the control flow is exception-driven, increased verbosity, etc.)

The key takeaway of the article is that the author kickstarted interest in extending the URL API so that people can actually validate URLs. Not many people are fond of the idea of "validation by running a function and seeing if it throws an exception".

> Not many people are fond of the idea of "validation by running a function and seeing if it throws an exception".

That's only because JS makes it unnecessarily verbose in the case where they don't care about the error message. It's exactly what they should want to do, rather than add another piece of the API to have to remember.

It's a nice tip (the existence of URL.parse) but doesn't scream "get shit done" like `import { parseUrl } from 'lib/url'` (or parseJson, etc)

Article's about a guy who doesn't like using try catch as control flow

Apparently he finds null checking better

"Exception" has a meaning. Exceptions are supposed to be used for just that, unexpected situations. Not being able to parse something is not an exception. It's a normal thing. RegEx doesn't throw an exception when there's no match. Array.indexOf doesn't throw an exception when it doesn't find a something.

It's really nice to able to go into the debugger and say "stop on all exceptions" and not be spammed with the wrong use of exceptions

And so, it's nice that we'll have `URL.parse`

If you're expecting a string to be a URL, failing to parse it as a URL is indeed an unexpected situation.

An invalid URL in a config file is exceptional. An invalid URL typed in by a user or from an external source (eg the body of an API request or inside of some HTML) is Tuesday.

You don't?

If that's the case, can you explain why?

Null checking can be fine if a failure mode is unambiguous. However, if an operation can fail for many reasons, it can be helpful to carry that information around in an object. For example with URL parsing, it might be nice to be able to know why parsing failed. Was it the lack of protocol? Bad path format? Bad domain format? Bad query format? Bad anchor format? This information could theoretically be passed back using an exception object, but this information is eliminated if null is returned.

Exceptions and null both require the caller to 'deal with it' verbosely, so neither saves lines of code.

But the only thing more annoying than a loud failure (exceptions) is a silent failure (null) which keeps executing.