catch throwable to suppress errors in Java

[bruno-garcia]

The goal is to change code locations we suppress error to avoid the SDK bubbling errors to customers.

Firs try: I changed every match of catch (Exception to catch (Throwable. Not matching Kotlin code though, the main focus was to help avoid the case we had when debugging a crash on Unity with the Android SDK so mainly sentry-java and sentry-android-core.

Adding additional logging isn't in the scope of this PR. When it was simple I just added a debug log, but if no logger available, I added a TODO and we can have a follow up PR.

@maciejwalkowiak does this make sense on the Spring and other backend packages or should I revert?

Partially addresses #1806 (not doing the Kotlin code)

[codecov-commenter]

Codecov Report

Merging #1812 (8311e42) into main (2d41eca) will not change coverage.
The diff coverage is 27.11%.

@@            Coverage Diff            @@
##               main    #1812   +/-   ##
=========================================
  Coverage     75.72%   75.72%           
  Complexity     2194     2194           
=========================================
  Files           218      218           
  Lines          7806     7806           
  Branches        828      828           
=========================================
  Hits           5911     5911           
  Misses         1493     1493           
  Partials        402      402           

Impacted Files	Coverage Δ
...ry/transport/apache/ApacheHttpClientTransport.java	68.91% <0.00%> (ø)
...main/java/io/sentry/spring/SentrySpringFilter.java	71.15% <0.00%> (ø)
...racing/SentrySpanClientHttpRequestInterceptor.java	0.00% <0.00%> (ø)
...ry/src/main/java/io/sentry/DirectoryProcessor.java	68.62% <0.00%> (ø)
...ry/SendCachedEnvelopeFireAndForgetIntegration.java	30.95% <0.00%> (ø)
...c/main/java/io/sentry/SentryCrashLastRunState.java	94.44% <0.00%> (ø)
.../main/java/io/sentry/SentryEnvelopeItemHeader.java	92.59% <0.00%> (ø)
...io/sentry/UncaughtExceptionHandlerIntegration.java	76.00% <0.00%> (ø)
...o/sentry/adapters/ContextsDeserializerAdapter.java	40.81% <0.00%> (ø)
...java/io/sentry/adapters/DateSerializerAdapter.java	42.85% <0.00%> (ø)
... and 31 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2d41eca...8311e42. Read the comment docs.

[maciejwalkowiak]

I don't see how this could hurt anything server side related. Looks good to me.

[marandaneto]

Missing specific catch blocks that don't use Exception but rather something specific eg RuntimeException, InterruptedException, ParseException, and many more.

Missing changes on Kotlin projects.

the PR description states that logging isn't the focus but resolves the issue #1806
The PR description describes that logging isn't part of this PR so either we don't close (resolve) #1806 or we open a new issue, we don't want to silently swallow a Throwable and not log out, it'd be even harder than crashing for debugging eventual issues.

Tests are not adjusted to using a Throwable error instead of Exception, so we cannot guarantee that those changes don't have a side effect during code execution (at least when testing)

[bruno-garcia]

Missing specific catch blocks that don't use Exception but rather something specific eg RuntimeException, InterruptedException, ParseException, and many more.

I wouldn't go that far. When we picked a specific exception type, the intent was to handle only that one. That implies already that any other type was supposed to bubble up so for that reason I wouldn't change those.

Missing changes on Kotlin projects.
the PR description states that logging isn't the focus but resolves the issue #1806 The PR description describes that logging isn't part of this PR so either we don't close (resolve) #1806 or we open a new issue, we don't want to silently swallow a Throwable and not log out, it'd be even harder than crashing for debugging eventual issues.

Fair point. I'll remove the Resolves from the PR. We can keep that for adding any missing logging and a linter so we don't have catch (Exception) anymore in the code base.

Tests are not adjusted to using a Throwable error instead of Exception, so we cannot guarantee that those changes don't have a side effect during code execution (at least when testing)

I'm not sure what we can test in this case. The intent of the code I changed was to suppress any unhandled error. It was done on the "wrong" exception type. I wrote many of those and as a C# dev I just wrote what I knew and missed the point Throwables could go through my catch block so it's just a correction of those.

[bruno-garcia]

Discussed on a call with @marandaneto and agreed to merge this not as resolving the inital issue but partially addressing it.