|
error_log($e->getMessage()); |
I've worked on PHP applications where error_log either wasn't properly configured, or the application used a completely separate logging infrastructure to log errors, exceptions, etc. It is probably a good idea to avoid letting exceptions be raised from DogStatsd::event, but I suspect it's less good to rely on error_log alone, as the client using the library may lose the error message, and/or lose the opportunity to do anything about the fact that the curl call failed.
One alternative could be to allow the client to inject an optional PSR-3 logger interface in the constructor, and then log to that on calls to DogStatsd::event. This is a very common strategy that provides the user of library code to make their own decisions about how to deal with errors, etc. Monolog, for example, provides a way to log to error_log, among a plethora of other things.
php-datadogstatsd/src/DogStatsd.php
Line 397 in 5b89937
I've worked on PHP applications where
error_logeither wasn't properly configured, or the application used a completely separate logging infrastructure to log errors, exceptions, etc. It is probably a good idea to avoid letting exceptions be raised fromDogStatsd::event, but I suspect it's less good to rely onerror_logalone, as the client using the library may lose the error message, and/or lose the opportunity to do anything about the fact that thecurlcall failed.One alternative could be to allow the client to inject an optional PSR-3 logger interface in the constructor, and then log to that on calls to
DogStatsd::event. This is a very common strategy that provides the user of library code to make their own decisions about how to deal with errors, etc. Monolog, for example, provides a way to log toerror_log, among a plethora of other things.