what is the best practice for custom authorizer in case of an exeptions

One approach to achieve the desired outcome would be to define your cache key and ensure that a request retrying after an error would not be triggering an existing cache key based on how the cache key is composesd.

API Gateway offers a caching key mechanism, which uniquely identifies a particular user in your custom authorizer. All the requests passing the same header will receive a cached response if the request is sent with an expiry time-frame. When a cached method or integration has parameters, which can take the form of custom headers, URL paths, or query strings, you can use some or all of the parameters to form cache keys. API Gateway can cache the method's responses, depending on the parameter values used.

See https://www.linkedin.com/pulse/aws-lambda-authorizer-patterns-caching-harshit-pandey/

Currently API Gateway is only caching when a policy is generated. I tested this by deliberately creating an syntax error in my lambda authorizer. The authorizer has caching enabled. The request did not get cached when I again called the API with the same identify source value from a client within the Authorizer cache TTL. The number of invocations of the Lambda authorizer matched with the count of API Gateway requests.