error_handler._ignore_error inadvertently suppresses non-exception error events

[seanupton]

Whether the logging of only exceptions (and no other error conditions) is the goal or not, the way that collective.sentry.error_handler._ignore_error deals with such assumes the presence of a non-null return value from sys.exc_info():

• the default exc_info value in the absense of an exception condition is (None, None, None)
• _ignore_error will trip over this with an AttributeError
• said AttributeError is relying on implied behavior of sentry_sdk handling of exceptions in before_send hooks described here: Exceptions in before_send are silenced getsentry/sentry-python#402 (comment)

There are cases where it is desirable to send events to Sentry for these non-exception conditions:

1. logging.ERROR and higher level log messages are always suppressed by the behavior described above
2. sentry_sdk.capture_message is always suppressed as side-effect of the behavior described above

I end up patching a wrapper around this in my site policy to make what gets sent to Sentry as more verbose:

_orig_ignore_error = collective.sentry.error_handler._ignore_error

def _ignore_error(event):
    if sys.exc_info() == (None, None, None):
        return False  # not exception, send event anyway
    return _orig_ignore_error(event)

Of course, a side-effect of having log messages and exceptions sent to Sentry as distinct events is an increase in the number of events sent. That is probably best an opt-in behavior (for now, my patch above achieves this, but the reason non-exception events are filtered out is here, really by accident, and probably should be handled with try/except around that AttributeError).

but whether or not sending logger.error('...') and sentry_sdk.capture_message('...') to Sentry is the intention of this integration (or simply out of its scope, and up to things like a monkey patch like above), it probably should not be relying on implicit suppression of errors in before_send by sentry_sdk.