Benchmark: try/catch vs check

Script Preparation code:

function log() {
  var str = "";
  for (var i = 0; i < arguments.length; ++i) {
    str += String(arguments[i]);
  }
}

var resA;
function doTry (e) {
  try {
    resA = e.details[0];
  } catch (err) {
    log("unexpected format of event:", err.toString());
  }
}

var resB;
function doCheck (e) {
  if (e && e.details) {
    resB = e.details[0];
  } else {
    log("unexpected format of event:", e);
  }
}

var goodEvents = [];
for (var i = 0; i < 10000; ++i) {
  goodEvents.push({ details: [ Math.random() ] });
}

var badEvents = [];
for (var i = 0; i < 10000; ++i) {
  if (i % 20 === 0) {
    badEvents.push(null);
  } else if (i % 20 === 10) {
    badEvents.push({});
  } else {
  	badEvents.push({ details: [ Math.random() ] });
  }
}

function test (events, fn) {
  for (var i = 0; i < events.length; ++i) {
    fn(events[i]);
  }
}

Tests:

try
test(goodEvents, doTry);
check
test(goodEvents, doCheck);
try (bad)
test(badEvents, doTry);
check (bad)
test(badEvents, doCheck);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
try
check
try (bad)
check (bad)

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Browser/OS: Chrome 124 on Windows

View result in a separate tab

Test name	Executions per second
try	1162.6 Ops/sec
check	1104.8 Ops/sec
try (bad)	104.3 Ops/sec
check (bad)	887.0 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's dive into the provided benchmark.

**Benchmark Definition**

The benchmark measures the performance difference between two approaches to handling event data: `try/catch` and explicit checks (`if-else` statement).

The script preparation code defines two functions, `doTry` and `doCheck`, which take an event object as input. The `goodEvents` and `badEvents` arrays are used to simulate valid and invalid event data.

**Options Compared**

There are four test cases:

1. **try**: This test case uses the `try/catch` approach with `doTry`.
2. **check**: This test case uses explicit checks (`if-else`) with `doCheck`.
3. **try (bad)**: This test case uses the `try/catch` approach but simulates invalid event data in `badEvents`.
4. **check (bad)**: This test case uses explicit checks (`if-else`) but simulates invalid event data in `badEvents`.

**Pros and Cons of Each Approach**

1. **try/catch**:
	* Pros:
		+ Can handle unexpected errors more elegantly.
		+ Reduces boilerplate code.
	* Cons:
		+ May incur performance overhead due to exception handling.
		+ Can lead to slower execution if not optimized properly.
2. **explicit checks** (`if-else`):
	* Pros:
		+ More predictable and controlled error handling.
		+ Can be more efficient than `try/catch` for simple cases.
	* Cons:
		+ Requires explicit checks for every possible condition.
		+ May lead to longer code and increased maintenance complexity.

**Library Usage**

The benchmark uses the `log` function, which is not a built-in JavaScript library. Instead, it appears to be a custom logging utility defined in the script preparation code. Its purpose is to print error messages or logs.

**Special JS Features/Syntax**

This benchmark does not explicitly use any special JavaScript features or syntax that would require specific handling or optimization.

**Other Considerations**

1. **Event Handling**: The benchmark simulates event data using arrays of objects, which may not accurately represent real-world event handling scenarios.
2. **Browser Variability**: The benchmark runs on multiple browsers (Chrome 124) and devices (Desktop), which can introduce variability in results due to differences in browser implementations and execution environments.

**Alternatives**

Other approaches to handling event data could include:

1. **Type guards**: Using type guards or other static analysis techniques to ensure event data is correctly formatted.
2. **Validation libraries**: Utilizing validation libraries like Joi or Yup to validate event data before processing it.
3. **Optimized error handling**: Implementing optimized error handling mechanisms, such as using `try`-`catch` blocks with specific error types or using error handling middleware.

Keep in mind that the choice of approach depends on the specific requirements and constraints of your application.

Related benchmarks:

try/catch vs check (version: 0)

Comparing performance of: try vs check vs try (bad) vs check (bad)

Created: 9 years ago by: Guest

Jump to the latest result

try

check

try (bad)

check (bad)

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):