re: Clean up your code with these tips! VIEW POST

FULL DISCUSSION
 

The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer. - Cunningham's Law

My try on this:

let secure = true;

try {
  secure = !window.location.hostname.match(/localhost|127\.0\.0\.1/);
} catch (e) {}

export default new Cookie({ secure });
 

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.

 

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 (e instanceof TypeError) {
    // statements to handle TypeError exceptions
  } else if (e instanceof RangeError) {
    // statements to handle RangeError exceptions
  } else if (e instanceof EvalError) {
    // statements to handle EvalError exceptions
  } else {
    // statements to handle any unspecified exceptions
    logMyErrors(e); // pass exception object to error handler
  }
}

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.

 

I am curious, with the "cunningham's law" post, are you stating that you think I'm wrong on my post? If so I'd be happy to hear why you think so.

 

No, I didn't think you were wrong. I had the impression you were searching for a more concise solution 🀣

It was to show others how they can clean up their code to make it smaller and easier to read. You're definitely does that. lol. Thanks for providing feedback.

 

Added this to the tips! Gave you credit.

code of conduct - report abuse