Just a coder and a dad. I love my family and I love to code!!!! started coding at 11, so I have 25 years under my belt. Still love learning about it every day. Black lives matter!
Just a coder and a dad. I love my family and I love to code!!!! started coding at 11, so I have 25 years under my belt. Still love learning about it every day. Black lives matter!
Sure! First I'd like to say that I find nothing wrong with your solution. I just prefer to avoid using try/catch as a way to soak up possible errors unless I plan on dealing with those errors.
I use try/catch when intentionally handling errors that would be thrown. Example borrowed from Mozilla for lack of valid example off top of head.
try{myroutine();// may throw three types of exceptions}catch(e){if(einstanceofTypeError){// statements to handle TypeError exceptions}elseif(einstanceofRangeError){// statements to handle RangeError exceptions}elseif(einstanceofEvalError){// statements to handle EvalError exceptions}else{// statements to handle any unspecified exceptionslogMyErrors(e);// pass exception object to error handler}}
This works and it reads clearly, but it is devoid of specificity.
You desire to control flow on state, not on error. Error is normally flow control failed.
The code tells nothing about what is expected, only it might fail in certain generic ways.
Try excepts are essentially GOTOs, as flow control they smell?
People will point to the performance hit, but creating the additional stack frame and even unwinding it is usually significant.
The variability of being able to optimize the code in the protected frame varies, so can hit perf noticably or nearly none.
Unless you are using ES7 try blocks are synchronous, so careful with this approach.
My real concern it is backwards and -to me- lazy. If your state is bad in a known detectable way why continue much less spread it to myroutine which may incur other side effects due to caller pollution. Then finding it assuming myroutine has some protection is up the call stack we go.
There are cases where this is the only real choice and there are cases where detection is expensive and or very rare so the trade-off might be compelling. Otherwise, if never approve the PR.
Just a coder and a dad. I love my family and I love to code!!!! started coding at 11, so I have 25 years under my belt. Still love learning about it every day. Black lives matter!
I appreciate that you donβt just accept it and you have an difference of opinion. The world would be boring if no one challenged others. I would love to see you write out the code to show what each of your points refer to.
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.
I have seen this and used it in the past. I am less likely to use this but it still gets the job done! And much smaller. Thanks for your feedback.
Mind to elaborate? π
Sure! First I'd like to say that I find nothing wrong with your solution. I just prefer to avoid using try/catch as a way to soak up possible errors unless I plan on dealing with those errors.
I use try/catch when intentionally handling errors that would be thrown. Example borrowed from Mozilla for lack of valid example off top of head.
I am clearly opinionated here :)
This works and it reads clearly, but it is devoid of specificity.
You desire to control flow on state, not on error. Error is normally flow control failed.
The code tells nothing about what is expected, only it might fail in certain generic ways.
Try excepts are essentially GOTOs, as flow control they smell?
People will point to the performance hit, but creating the additional stack frame and even unwinding it is usually significant.
The variability of being able to optimize the code in the protected frame varies, so can hit perf noticably or nearly none.
Unless you are using ES7 try blocks are synchronous, so careful with this approach.
My real concern it is backwards and -to me- lazy. If your state is bad in a known detectable way why continue much less spread it to myroutine which may incur other side effects due to caller pollution. Then finding it assuming myroutine has some protection is up the call stack we go.
There are cases where this is the only real choice and there are cases where detection is expensive and or very rare so the trade-off might be compelling. Otherwise, if never approve the PR.
I appreciate that you donβt just accept it and you have an difference of opinion. The world would be boring if no one challenged others. I would love to see you write out the code to show what each of your points refer to.