Feature request: Automatically log exceptions using sys.eventhook
See original GitHub issueUse case
I find myself often writing a generic try/except statement in my handler to always log all exceptions. I’m not sure if this is a good pattern, maybe it already does this, so I might just be looking for guidance on current practices. (I didn’t see anything in the docs or other issues on this.)
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.typing import LambdaContext
logger = Logger()
@logger.inject_lambda_context
def handler(event: dict, context: LambdaContext) -> str:
try:
return "hello world"
except Exception:
logger.exception("Caught an unhandled error")
raise
Solution/User Experience
What I’ve done in CLI utilities to capture those exceptions to the logger, is to override the sys.eventhook
. This way, every exception is logged automatically. Would it be useful to do something similar for lambda functions?
def exception_hook(exc_type, exc_value, exc_traceback):
"""Log unhandled exceptions with hook for sys.excepthook."""
log = logging.getLogger(service_name)
log.exception(
'',
exc_info=(exc_type, exc_value, exc_traceback)
)
sys.excepthook = exception_hook
Alternative solutions
No response
Acknowledgment
- This feature request meets Lambda Powertools Tenets
- Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:13 (7 by maintainers)
Top Results From Across the Web
Logging uncaught exceptions in Python - Stack Overflow
But my situation is such that it would be really nice if logging.exception(...) were invoked automatically whenever an exception isn't caught. python ·...
Read more >Event Types | Okta Developer
The following is a full listing of event types used in the System Log API with associated description and related metadata.
Read more >Error Handling | Documentation - ServiceStack Docs
All Exceptions get injected into the ResponseStatus property of your Response DTO that is serialized into your ServiceClient's preferred Content-Type making ...
Read more >Event Hubs messaging exceptions - .NET (legacy)
This article provides a list of Azure Event Hubs messaging exceptions and suggested actions.
Read more >Requests Documentation - Read the Docs
Requests will automatically decode content from the server. ... In case the JSON decoding fails, r.json() raises an exception.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Great to hear @davideicardi !
As to your question, this is a hook for any exception that was either raised intentionally OR unforeseen. For the
ServiceError
case, Powertools will catch it and convert into a successful exit ({“statusCode”: 500, …}).For the flexibility, we could still have a method where you provide your own function to handle any uncaught exception, like
set_exception_hook
. I initially thought of having a list of exceptions, “allow_list” if you will, but the premise that @lorengordon and Python docs states is primarily for uncaught exceptions – If you know what the exception is, it’s still business as usual since you can catch, log the exception withlogger.exception
, and decide whether to re-raise or handle gracefully.For example:
Raised intentionally
Unexpected/unforeseen exception
Yes, we can figure out naming in a PR. Perhaps
Logger(log_uncaught_exceptions=True)
, and in the docstring (and docs) we call out the the hook.This makes it easier for other Powertools languages to reword
exception
toerror
and keep a similar UX 😉I’m working on a few other issues now, but if you have the bandwidth to send a PR, we can include it in the next release!!