Better Error Reporting for the New Architecture #122
krystofwoldrich
started this conversation in
Deep Dive
Replies: 1 comment 1 reply
-
Thanks, this is awesome! What do you think? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
After adding support for React Native New Architecture to the @sentry/react-native error and performance monitoring library, we (@marandaneto, @kahest, @krystofwoldrich) noticed that Turbo Modules report errors differently than the original Native Modules. In some cases, parts of the stack trace were missing. We teamed up with @cortinico and @cipolleschi to investigate the changes and create this overview.
The goal of this post is to document the current state and compare this to expectations, and finally derive tasks and initiatives for improvement.
Summary
Legend
✅ All as expected (note something might be missing but it’s not subject to change)
⚠️ Missing part of the stack (JS or JAVA/ObjC or CPP)⚠️ Crashed App in Dev build and missing part of the stack
🚨 Crashed App in Dev build
🚨
Tests
Every entry has an
expected
field describing the ideal situation of what should the error reporting contain andactual
describing what is currently reported. Theexpected
is subject to change and the reason for this post is so we can align and discuss what should be reported and how.Javascript
Besides
console.error
RedBox not pointing to the correct line everything works as expected.This section consists of errors with a cause in Javascript code. Besides a minor issue with
RedBox
. This is more for completes of the overview.✅ Error
Expected - stack trace points to the JS error
Actual - stack trace points to the JS error
(iOS doesn’t show RedBox, but the stack trace is correct)
Screenshots
Expected - stack trace points to
console.error
Actual - stack trace point to the synthetic error
Screenshots
✅ YellowBox
Expected - stack trace points to the
console.warn
Actual - stack trace points to the
console.warn
Screenshots
Turbo Modules
This section describes errors with a cause in Turbo Modules code, Kotlin, Java, or Objective-C.
Errors thrown in Turbo Modules behave differently based on the module function signature. We found that void functions throw Java/Obj-C errors and do not bubble to JS but functions with return values throw JS errors (without platform stack trace). Asserts work similarly.
Expected - stack trace points to the Java RuntimeException/NSException including the JS stack trace
Actual - stack trace points to the Java RuntimeException/NSException only or to the JavaScript Error only based on the method signature there are different outcomes.
For example
void function
throws an error in Java/Objective-C and no error bubbles up to Javascript,bool function
bubbles the error to Javascript but without any additional information, no platform stack trace. We consider this the most important of all the findings.Note for iOS: Xcode debugger stops the app during a crash and the developer has access to the stack, so showing the error on the screen doesn't make send in that case. Buf if someone is developing their app using
react-native cli
seeing the error on the screen the same way as in Android would be a large improvement to the dev experience.Here is a branch with a new test added to
rn-tester
showing different behavior based on the method signature.facebook/react-native@main...krystofwoldrich:react-native:kw-turbo-modules-errors-tests
Screenshots
No iOS screenshots as the app crashes even in Dev build.
Stack traces
Kotlin stack trace
Objective-C stack trace
Expected - stack trace points to the Java Assert/RCTAssert with JS stack trace (should not crash in Dev build)
Actual - stack trace points to the Java Assert/RCTAssert
Screenshots
No screenshots as the app crashes even in Dev build.
Stack traces
Kotlin stack trace
Objective-C stack trace
CPP Modules
Errors thrown in the CPP bubble to JS without the CPP stack trace. Asserts crash the app, CPP stack trace can be retrieved from crash reports.
Expected - CPP stack trace and JS stack trace
Actual - JS stack trace only
Screenshots
Stack traces
Android stack trace
iOS stack trace
Expected - CPP stack trace and JS stack trace (no crash in dev build)
Actual - CPP stack trace only
Screenshots
No screenshots as the app crashes even in Dev build.
Stack traces
Android stack trace
iOS stack trace from Crash Report
Native Modules (Legacy)
Due to the Bridge limitations (async and batching) bubbling the errors would not be possible. We don't expect any changes here.
✅ Java/Kotlin Error
Expected - stack trace points to the Java RuntimeException
Actual - stack trace points to the Java RuntimeException
Screenshots
Stack traces
Kotlin stack trace
Expected - stack trace points to the Java Assert
Actual - stack trace points to the Java RuntimeException
Screenshots
Stack traces
Kotlin stack trace
Beta Was this translation helpful? Give feedback.
All reactions