Closed lkhari closed 4 years ago
@lkhari while I think it's a good option to have, I don't understand why you wouldn't want an error log message in the case of Step Functions and AppSync resolver functions. Can you clarify?
An example is, on the site i'm working we have very little frontend validation. So often the requests come to the backend through appsync and aren't suited due to incorrect dates etc. I can't return the message back through graphql since it's expecting a specific entity, so I throw a validation error.
I use error logging as more high priority issues which require fixing urgently, which these validation errors are often not an issue so i log them as warnings.
That's my reason, but I can also see people wanting to be able to format the message diffferently like in issue #98
Note: if you have a better way of returning validation errors, i'm happy to hear.
mm.. I see, the problem here is that when something does go wrong (not related to validation) then you also won't have those error log messages, which captures the invocation event, etc.
Yea, that is true. I think, to be honest, if you have made the decision to turn off the error catching in this package, then you most likely going to understand that you must handle errors in your code.
fixed by #146
This is a Feature Proposal
Description
Similar or dependent issues:
98