Sentry::Error represents errors SDK raises intentionally.
Sentry::ExternalError represents errors by the SDK, but casused by
external reasons, like networking issues.

The code invoked by the SDK itself, whether it's an external service
call (like sending events) or a user-defined callback (like async or
before_send), shouldn't cause the user's application to crash.

Although some may think errors caused by user-defined callbacks should
be raised for debugging purpose, it's actually a bad practice in reality.

Most of the users only activate the SDK in production and they don't write
tests for the callbacks. So if there's any bug in the callbacks,
they will usually be spotted in production.

Also, because the SDK is usually placed at the farthest layer of the
app to catch all the possible exceptions, there won't be anything to
capture exceptions triggered by the SDK.

So from the SDK's perspective, we can either raise them or swallow them:

- If we raise them, the user's customers will see broken apps. Good for
  spotting bugs, very bad user experience.
- If we rescue them, the user's customers won't spot a thing. It may be
  harder for the user to spot the buggy callback, but at least their
  customers won't be angry.

This is why I decided to swallow any errors happen in the
`Client#capture_event`.