1) The if part: I meant making an early decisions may add more flexibility to your code for example
// You may use this()=>{if(condition1){return1;}// Maybe another logic in betweenif(condition2){return2;}returndefault;}// Instead of this()=>{if(condition1){return1;}elseif(condition2){return2;}else{returndefault;}}
Usually, it would make the code more readable and maintainable.
2) Well, my statement regarding the run-time exception was a little bit biased by the Open-Closed Principal as I mentioned. Which suggests making the code extensible without actually changing the base code itself.
Another reasons I was thinking about:
Not all languages are compiled.
May be another developer or team ( That happens he/it is not a big fan of Typescript ) try to use the JavaScript version of your code.
In some cases may be the user try to maliciously change the values (for example your are expecting values from a predefined select menu => the user may alter the values before sending them).
As I said earlier it's a personal taste and not related exactly to your specific example.
3) I think that we have to be creative about this point, making an application that is tolerant to run-time errors is always challenging and great (Maybe for your example, you can use the previous state as a fallback when a signal is not defined or maybe you can define an emergency safe state that avoids all damage maybe a pull-over state ). Also, it totally depends on the situation for uses cases with low tolerance to errors your approach may be appropriate for extent ( still you are not dealing with unexpected run-time errors ).
I hope that you got what I'm trying to illustrate.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As I mentioned I was talking In General.
1) The
if
part: I meant making an early decisions may add more flexibility to your code for exampleUsually, it would make the code more readable and maintainable.
2) Well, my statement regarding the run-time exception was a little bit biased by the Open-Closed Principal as I mentioned. Which suggests making the code extensible without actually changing the base code itself.
Another reasons I was thinking about:
3) I think that we have to be creative about this point, making an application that is tolerant to run-time errors is always challenging and great (Maybe for your example, you can use the previous state as a fallback when a signal is not defined or maybe you can define an emergency safe state that avoids all damage maybe a pull-over state ). Also, it totally depends on the situation for uses cases with low tolerance to errors your approach may be appropriate for extent ( still you are not dealing with unexpected run-time errors ).
I hope that you got what I'm trying to illustrate.