fix(performanceTimer): throwing in axe catch clause

[WilcoFiers]

I ran into a problem with this:

axe-core/lib/core/base/rule.js

Lines 297 to 300 in e7dae4e

	if (options.performanceTimer) {
	this._logRulePerformance();
	}
	reject(error);

If the end mark isn't set, performance.measure throws an error. Since we call performance.measure in the catch, it is quite possible that the end mark doesn't exist. And then throwing from a catch completely throws the run. I don't think axe should fail if the performance measure fails, so instead I'm going to have it just log the error and move forward.

[Copilot]

Pull Request Overview

This PR fixes a critical issue where the performanceTimer.measure method would throw an error if performance marks don't exist, which could cause the entire axe-core run to fail when called from catch blocks. The fix wraps the performance.measure call in a try-catch block to log errors instead of propagating them.

• Added error handling to prevent performance measurement failures from breaking axe runs
• Added comprehensive test coverage for error scenarios in the measure method

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
lib/core/utils/performance-timer.js	Added try-catch wrapper around performance.measure to log errors instead of throwing
test/core/utils/performance-timer.js	Added test cases for error handling when performance marks are missing

[Copilot]

Logging the raw error object may not provide useful information to users. Consider logging a more descriptive error message like this._log('Performance measurement failed: ' + e.message); to make the logged error more helpful.

Suggested change

	this._log(e);
	this._log('Performance measurement failed: ' + (e && e.message ? e.message : e));