feat(develop): Add clarification for capturing internal exceptions in SDKs

Author: sl0thentr0py

develop-docs/sdk/overview.mdx

@@ -294,6 +294,8 @@ happens immediately that may result in a different response code (and message).
 
 ## Handling Errors
 
+### Server Errors
+
 We **highly encourage** that your SDK handle failures from the Sentry server
 gracefully. Specifically, SDKs must honor the `429` status code and not attempt
 sending until the `Retry-After` kicks in. SDKs should drop events if Sentry is
@@ -328,6 +330,19 @@ Retrying too often may cause further rate limiting or blocking by the Sentry
 server.
 </Alert>
 
+### SDK Errors
+
+We try our best to make our SDKs error-free. We are an exception monitoring service after all
+and throwing our own exceptions is awkward. However, if our SDKs do throw exceptions, we have to make
+sure we swallow them gracefully and emit an error level log describing the failure.
+
+As a **design principle**, we never capture Sentry events for exceptions happening within our SDKs.
+This includes user-defined callbacks and hooks such as `before_send`, `traces_sampler` and so on.
+
+The main justification for this is that we are already in an event capturing flow where the scope has been applied
+and capturing another event at that point in the lifecycle would lead to undefined behavior. In the worst case,
+we could create a busy loop of creating and sending events repeatedly till the system crashes.
+
 ## Concurrency (Scope and Hubs)
 
 SDKs are supposed to provide standardized concurrency handling through the