That is true to a point but these issues are still true for the network calls. iirc I have a video like "The type is a lie" where I show some basic ideas on how to solve that problem, the short version is that you can trust TypeScript as long as you validate the data that comes over the network in a similar manner to how a strictly typed server would serialise data in to a object. Have a great day and thank you so much for watching!
I suppose the way I think about it is that we should ask how we want to communicate that something is wrong, perhaps throwing a error for a minor piece of logic isn't the way to go if it breaks the entire application but rather logging the error is an alternative, that being said it ofc depends on the nature of the error when we are deciding what to do when something goes wrong. Have a great day and thank you so much for watching!
Do you not think it's better for the application to crash than to continue on running in an deterministic way? Let's say you have the following: const totalPrice = add(itemPrice, taxes); If for some reason taxes would become some invalid value due to a coding error, I would rather have my application crash then to accidentally start selling everything at an accidental discount. It's also a massive pain to work with a codebase where the errors are swallowed, you never know if there is a genuine error in your code, nothing will tell you. It will be very hard to find the source of the error if every single function is written in a way that they swallow errors.
That is true but let me counter with, do you prefer that your checkout page crashes and stops sales if the failing logic is to correctly extract the display text for the newsletter signup link? I stand by that the nature of the error should determine the behaviour and throwing an error or crashing is not imo the best course of action for every issue. Have a great day and thank you so much for watching!
try { doMyLogicThatMightFail(); } catch (e) { logErrorAndFailGracefully(); } There is a difference between attempting to make decisions about errors on a functional level and doing it on a high level. There is a difference between rendering some random UI that happens to somewhat work and being explicit about what happens on failure.
There are plenty of functions even in the standards that have this behaviour an example would be indexOf. const index = [1, 2, 3].indexOf(4); Why isn't this throwing an error but rather returning -1? Even if we would rewrite indexOf to throw an error the difference is a try catch vs an if statement to check the return value and the code you provided could be rewritten: const value = doMyLogicThatMightFail(); if(value === -1) { logErrorAndFailGracefully(); } If we want to be picky and talk about how to make a poor version of the try catch: try { doMyLogicThatMightFail(); } catch (e) {} I prefer a try catch solution when the error could be caused by many different things and I need to express what was wrong personally but that is ofc just me. Have a great day and thank you so much for watching!
