-
Notifications
You must be signed in to change notification settings - Fork 69
Avoid doing console.error #333
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Thanks @satazor for opening this issue. It actually looks like there are only two calls to sdk-javascript/src/message/http/index.ts Line 51 in 6cd310c
I think probably the one you note is the only one that should be removed, as the one in |
@lance 👍 For informal logs, please consider adding the ability to specify the logger (maybe with the same interface as console), so that we can override with custom loggers. |
This issue is stale because it has been open 30 days with no activity. |
* When receiving an event, we should not default the specversion to 1.0 if no specverion field is detected. * If no specversion is detected or the specversion does not conform to a currently supported version, we will now throw a ValidationError This is a BREAKING_CHANGE fixes cloudevents#332, cloudevents#333 Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
* When receiving an event, we should not default the specversion to 1.0 if no specverion field is detected. * If no specversion is detected or the specversion does not conform to a currently supported version, we will now throw a ValidationError This is a BREAKING_CHANGE fixes cloudevents#332, cloudevents#333 Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
Even if the specversion is totally invalid, we should not change the value received in an incoming `Message`. Previously we defaulted to 1.0 if we did not recognize the version number. This commit changes that, leaving the value unmodified. We default to parsing this mystery event with the 1.0 spec. When the event is validated with `event.validate()` we return `false`. One additional small change to eliminate a prettier warning about `parer` being previously declared. Fixes: cloudevents#332 Fixes: cloudevents#333 Signed-off-by: Lance Ball <lball@redhat.com>
Even if the specversion is totally invalid, we should not change the value received in an incoming `Message`. Previously we defaulted to 1.0 if we did not recognize the version number. This commit changes that, leaving the value unmodified. We default to parsing this mystery event with the 1.0 spec. When the event is validated with `event.validate()` we return `false`. One additional small change to eliminate a prettier warning about `parer` being previously declared. Fixes: #332 Fixes: #333 Signed-off-by: Lance Ball <lball@redhat.com>
Even if the specversion is totally invalid, we should not change the value received in an incoming `Message`. Previously we defaulted to 1.0 if we did not recognize the version number. This commit changes that, leaving the value unmodified. We default to parsing this mystery event with the 1.0 spec. When the event is validated with `event.validate()` we return `false`. One additional small change to eliminate a prettier warning about `parer` being previously declared. Fixes: cloudevents#332 Fixes: cloudevents#333 Signed-off-by: Lance Ball <lball@redhat.com>
This is not really a bug, nor a feature request, so I haven't followed any of the templates.
It seems
console.error
is being used in several situations, e.g.:sdk-javascript/src/event/cloudevent.ts
Line 170 in 6cd310c
In most scenarios, these
console.error
calls are unnecessary as errors will be thrown anyway, that should be handled by devs consuming this library. In other situations, errors aren't thrown, and these messages are useful. However, most devs are using custom loggers (like JSON loggers), and would like to be able to customize the logging behavior.The text was updated successfully, but these errors were encountered: