feat: implement guard support (#24)

[Groupguanfang]

No description provided.

[Copilot]

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

[Copilot]

[nitpick] Chaining two consecutive .catch calls on _stringifyAsync may hide errors rather than handling them explicitly. Consider refactoring this logic with a try-catch block for clearer and more reliable error handling.

Suggested change

	return await this._stringifyAsync(data)
	.catch(async error => this._stringifyAsync({
	statusCode: 500,
	message: 'Internal Server Error',
	error: await this._toReadableError(error),
	}))
	.catch(async error => this._stringifyAsync({
	statusCode: 500,
	message: 'Internal Server Error',
	error: await this._toReadableError(error),
	}))
	try {
	return await this._stringifyAsync(data)
	} catch (error) {
	try {
	return await this._stringifyAsync({
	statusCode: 500,
	message: 'Internal Server Error',
	error: await this._toReadableError(error),
	})
	} catch (nestedError) {
	return await this._stringifyAsync({
	statusCode: 500,
	message: 'Internal Server Error',
	error: await this._toReadableError(nestedError),
	})
	}
	}

[Copilot]

The guard execution does not include error handling; if guard.canActivate throws an exception, it could lead to unhandled errors. Consider wrapping this call in a try-catch block to provide a controlled failure response.

Suggested change

	const canActivate = await guard.canActivate(context)
	if (canActivate === true)
	continue
	return false
	try {
	const canActivate = await guard.canActivate(context)
	if (canActivate === true)
	continue
	return false
	} catch (error) {
	// Log the error or handle it as needed
	console.error('Error in guard.canActivate:', error)
	return false
	}