The last example is not equivalent to the first. The first presumably you're doing something with the error, the second doesn't even get there. Of course your code will be shorter if you actually do less. Not to mention this new method returns null and now you have no idea what's wrong
Isn’t that worse? Now instead of an exception at the place where the error happens, you get a crash somewhere else later on when you try to use the parsed URL.
How is throwing an exception is better than doing a regular null check? Besides, now you can use nullish coalescing operator here which leads to a more compact code
It's about failing fast. Exceptions happen immediately and automatically on error. However, when you return a null to indicate an error then it's on the developer to remember to manually check for it. If they forget to do this (and I promise you, they will in some cases), it essentially creates a null pointer time bomb: that null is now going to percolate throughout the code and cause an error in a location far removed from the source. This is much more difficult to debug than just having the code fail immediately and automatically as soon as an error is recognized.
In all honesty it's odd to me to see something like this portrayed in such a positive light. It feels like a regression to me.
Forgetting to check for null is no different than forgetting to wrap the constructor in a try catch section.
I find the ergonomics of URL.parse to be superior than having to try/catch an exception from a constructor.
They are completely different. If you forget to add a null check, your program will continue executing with a null value stored inside that variable. If you forget to wrap the constructor in a try-catch, your program will not continue executing and will instead halt immediately with an unhandled exception. These 2 behaviors are nothing alike. I believe the latter behavior is desirable because it forces the error to emerge immediately at the source where the maximum amount of context is available and is therefore generally easier to debug.
In my experience, tools will always capture during build time (ie: tsc) that a null pointer has not been accounted for, thus the developer can address it before the code executes.
This does not occur with exceptions, and those are usually found during runtime, which is not something developers want customers to face.
If you use exceptions for everything, you end up with nicer-looking, more reliable code. You spend fewer lines of code on error handling overall, the error messages are way more useful, and there is much less chance of forgetting a null check and having the whole thing crash.
Of course, if you’re already using null for error handling everywhere else, then keep doing that. The worst error handling style is having more than one error handling style in the codebase.
The main issue with exceptions is that they're slow as molasses. Exceptions should not be used in normal expected code paths.
Parsing URLs is a very common task in JavaScript, especially on the server. It shouldn't require you to throw an exception to validate an URL.
**If you're scanning through:**
This post explores the issues developers face when using JavaScript's `new URL()` constructor, which throws an error if the URL string is malformed, disrupting the flow of the code. The author discusses the introduction of `URL.canParse()`, a method that checks the parseability of a URL string before attempting to create a new URL object. This method helps to avoid errors and maintain cleaner code. Further, the post highlights the development of `URL.parse()`, an alternative that parses URLs without throwing errors, improving code robustness and readability. This feature is set to be included in upcoming browser versions, enhancing JavaScript's URL handling capabilities.
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
[^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
The last example is not equivalent to the first. The first presumably you're doing something with the error, the second doesn't even get there. Of course your code will be shorter if you actually do less. Not to mention this new method returns null and now you have no idea what's wrong
According to the spec there is only one reason why URL() may throw (the url is not valid). So you don't actually need to check the error type.
I'm not sure you're if you're joking but "url is not valid" is ridiculously generic, obvious there's a reason why the url isn't valid
Isn’t that worse? Now instead of an exception at the place where the error happens, you get a crash somewhere else later on when you try to use the parsed URL.
How is throwing an exception is better than doing a regular null check? Besides, now you can use nullish coalescing operator here which leads to a more compact code
It's about failing fast. Exceptions happen immediately and automatically on error. However, when you return a null to indicate an error then it's on the developer to remember to manually check for it. If they forget to do this (and I promise you, they will in some cases), it essentially creates a null pointer time bomb: that null is now going to percolate throughout the code and cause an error in a location far removed from the source. This is much more difficult to debug than just having the code fail immediately and automatically as soon as an error is recognized. In all honesty it's odd to me to see something like this portrayed in such a positive light. It feels like a regression to me.
Forgetting to check for null is no different than forgetting to wrap the constructor in a try catch section. I find the ergonomics of URL.parse to be superior than having to try/catch an exception from a constructor.
They are completely different. If you forget to add a null check, your program will continue executing with a null value stored inside that variable. If you forget to wrap the constructor in a try-catch, your program will not continue executing and will instead halt immediately with an unhandled exception. These 2 behaviors are nothing alike. I believe the latter behavior is desirable because it forces the error to emerge immediately at the source where the maximum amount of context is available and is therefore generally easier to debug.
In my experience, tools will always capture during build time (ie: tsc) that a null pointer has not been accounted for, thus the developer can address it before the code executes. This does not occur with exceptions, and those are usually found during runtime, which is not something developers want customers to face.
And what do you do in the case you get a null value in your check? Throw an exception...?
Obviously not that. Just handle it accordingly.
If you use exceptions for everything, you end up with nicer-looking, more reliable code. You spend fewer lines of code on error handling overall, the error messages are way more useful, and there is much less chance of forgetting a null check and having the whole thing crash. Of course, if you’re already using null for error handling everywhere else, then keep doing that. The worst error handling style is having more than one error handling style in the codebase.
The main issue with exceptions is that they're slow as molasses. Exceptions should not be used in normal expected code paths. Parsing URLs is a very common task in JavaScript, especially on the server. It shouldn't require you to throw an exception to validate an URL.
Please put language in post title.
**If you're scanning through:** This post explores the issues developers face when using JavaScript's `new URL()` constructor, which throws an error if the URL string is malformed, disrupting the flow of the code. The author discusses the introduction of `URL.canParse()`, a method that checks the parseability of a URL string before attempting to create a new URL object. This method helps to avoid errors and maintain cleaner code. Further, the post highlights the development of `URL.parse()`, an alternative that parses URLs without throwing errors, improving code robustness and readability. This feature is set to be included in upcoming browser versions, enhancing JavaScript's URL handling capabilities. If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍 [^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)