Is try-catch faster than fail only if-else?

Question

My situation is I have a small javascript program running on a huge amount of data formatted as a 2 dimensions array. For every cycle, it loops through the data, calls a serializer method to serialize that record before doing the calculations. The data for every cycle will be the same. So now I want to cache the serialized data into another array so that from the second time it doesn't have to call serializer again.

Here is my function:

  var cached=[];
  function getRow(x,y){
    if(!cached[x]){
      cached[x] = [];
    }
    if(!cached[x][y]){
      cached[x][y] = serializer(data,x,y);
    }
    return cached[x][y] ;
  }

So far it works. But as you can see, for every row it must check 2 conditions before returning cached data and the condition only helpful in the first cycle. So I'm thinking about using try-catch instead of if-else to handle it. So that in the first cycle, the try block will fail all the time then I will fill up the cache in catch block. Then after the first cycle when all the data has been cached, it will just get the value right the way and return it.

But my concern is: is it faster by doing that or try-catch will slow down the function and the performance just the same?

`try catch` is definitely a performance risk, because it makes optimization hard. — Pointy, Apr 20 '18 at 13:18
the default assumption should be `try-catch` (if used - exception really thrown) is slower than almost any alternative. — ASDFGerte, Apr 20 '18 at 13:20
[Branch prediction](https://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array/11227902#11227902), I guess you need not worry about 2 ifs because compiler itself optimizes it. — Satish Kumar, Apr 20 '18 at 13:21
maybe you take the `in` operator instead of returning an object. — Nina Scholz, Apr 20 '18 at 13:21
If you can't trust the sub-function tree that's called in that function, you can use `try catch` block to prevent any other's mistakes. But if the exception needs to be handled on some of the parents of that function, you need that exception to be thrown. — Taha Paksu, Apr 20 '18 at 13:54
I decided to ask because first the data is huge so it takes a lot of time. Secondly, I think there might be other developers wanted to know the answer also. And the last thing is, I want to learn how other peoples in the community solve a problem like this. — Hank Phung, Apr 20 '18 at 15:50

Scott Marcus · Accepted Answer · 2018-04-20T13:42:03.610

try/catch is only going to be more efficient in situations where no error is thrown. And, let's be clear, with modern clients, the increase in efficiency is going to be marginal and probably not noticeable in most applications.

When errors are thrown, performance will suffer because an error object is instantiated and configured, a scope is created for that error object to exist within and (of course) the JS runtime has to recover from the error.

In my experience, try/catch is generally used incorrectly in the first place. It should not be a matter of "choice" to use try/catch, it should be a matter or necessity. If there is a chance your code can cause an error and there is a way for you to code it to avoid that error, do that - - no try/catch needed.

Examples:

Errors that can occur because of bad user input should be dealt with by re-thinking the UI and how the input is processed.
Errors that can occur because of a bad interaction with a remote source (think AJAX) generally have error and timeout callback options.

If there is a way for your code to throw an error and it is beyond the control of your code (network outage, server error), try/catch may be necessary. I say may because many APIs these days have error callback functions to handle these kinds of things.

In short, you should never just choose try/catch. try/catch is a language feature to be used when no other solution is available.

`In my experience, try/catch is generally used incorrectly in the first place` agreed - `try/catch` should not be used as flow control as OP suggests and I've seen it employed - it is a method of error handling. In some cases you may even wish to forego it, if you are OK with the error being thrown. — VLAZ, Apr 20 '18 at 13:38
@vlaz Agreed. I am sometimes horrified to find developers encapsulating all of their function's code in a single `try/catch` as a "catch all". — Scott Marcus, Apr 20 '18 at 13:40

Is try-catch faster than fail only if-else?

1 Answers1