react-native-macos/React/CxxModule/RCTNativeModule.mm

132 строки
4.0 KiB
Plaintext
Исходник Обычный вид История

/*
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
#import "RCTNativeModule.h"
#import <React/RCTBridge.h>
#import <React/RCTBridgeMethod.h>
#import <React/RCTBridgeModule.h>
#import <React/RCTCxxUtils.h>
#import <React/RCTFollyConvert.h>
#import <React/RCTLog.h>
#import <React/RCTProfile.h>
#import <React/RCTUtils.h>
#ifdef WITH_FBSYSTRACE
#include <fbsystrace.h>
#endif
namespace facebook {
namespace react {
static MethodCallResult invokeInner(RCTBridge *bridge, RCTModuleData *moduleData, unsigned int methodId, const folly::dynamic &params);
RCTNativeModule::RCTNativeModule(RCTBridge *bridge, RCTModuleData *moduleData)
: m_bridge(bridge)
, m_moduleData(moduleData) {}
std::string RCTNativeModule::getName() {
return [m_moduleData.name UTF8String];
}
std::vector<MethodDescriptor> RCTNativeModule::getMethods() {
std::vector<MethodDescriptor> descs;
for (id<RCTBridgeMethod> method in m_moduleData.methods) {
descs.emplace_back(
method.JSMethodName,
RCTFunctionDescriptorFromType(method.functionType)
);
}
return descs;
}
folly::dynamic RCTNativeModule::getConstants() {
RCT_PROFILE_BEGIN_EVENT(RCTProfileTagAlways,
@"[RCTNativeModule getConstants] moduleData.exportedConstants", nil);
NSDictionary *constants = m_moduleData.exportedConstants;
folly::dynamic ret = convertIdToFollyDynamic(constants);
RCT_PROFILE_END_EVENT(RCTProfileTagAlways, @"");
return ret;
}
void RCTNativeModule::invoke(unsigned int methodId, folly::dynamic &&params, int callId) {
// capture by weak pointer so that we can safely use these variables in a callback
__weak RCTBridge *weakBridge = m_bridge;
__weak RCTModuleData *weakModuleData = m_moduleData;
// The BatchedBridge version of this buckets all the callbacks by thread, and
// queues one block on each. This is much simpler; we'll see how it goes and
// iterate.
dispatch_block_t block = [weakBridge, weakModuleData, methodId, params=std::move(params), callId] {
#ifdef WITH_FBSYSTRACE
if (callId != -1) {
fbsystrace_end_async_flow(TRACE_TAG_REACT_APPS, "native", callId);
}
#else
(void)(callId);
#endif
invokeInner(weakBridge, weakModuleData, methodId, std::move(params));
};
dispatch_queue_t queue = m_moduleData.methodQueue;
if (queue == RCTJSThread) {
block();
} else if (queue) {
dispatch_async(queue, block);
}
#ifdef RCT_DEV
if (!queue) {
RCTLog(@"Attempted to invoke `%u` (method ID) on `%@` (NativeModule name) without a method queue.",
methodId, m_moduleData.name);
}
#endif
}
MethodCallResult RCTNativeModule::callSerializableNativeHook(unsigned int reactMethodId, folly::dynamic &&params) {
return invokeInner(m_bridge, m_moduleData, reactMethodId, params);
}
static MethodCallResult invokeInner(RCTBridge *bridge, RCTModuleData *moduleData, unsigned int methodId, const folly::dynamic &params) {
if (!bridge || !bridge.valid || !moduleData) {
return folly::none;
}
id<RCTBridgeMethod> method = moduleData.methods[methodId];
if (RCT_DEBUG && !method) {
RCTLogError(@"Unknown methodID: %ud for module: %@",
methodId, moduleData.name);
}
NSArray *objcParams = convertFollyDynamicToId(params);
@try {
id result = [method invokeWithBridge:bridge module:moduleData.instance arguments:objcParams];
return convertIdToFollyDynamic(result);
}
@catch (NSException *exception) {
// Pass on JS exceptions
if ([exception.name hasPrefix:RCTFatalExceptionName]) {
@throw exception;
}
Crash reporting heaven (#23691) Summary: <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot. But native crashes were (and still are) much harder to diagnose. ..Until now :D I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help. The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr). I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly. I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling. After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it. In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`. The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym. I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code. Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost! Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice. I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above. [iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them. [General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode. Pull Request resolved: https://github.com/facebook/react-native/pull/23691 Reviewed By: fkgozali Differential Revision: D14276366 Pulled By: cpojer fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
2019-03-13 05:24:07 +03:00
#if RCT_DEBUG
NSString *message = [NSString stringWithFormat:
@"Exception '%@' was thrown while invoking %s on target %@ with params %@\ncallstack: %@",
exception, method.JSMethodName, moduleData.name, objcParams, exception.callStackSymbols];
RCTFatal(RCTErrorWithMessage(message));
Crash reporting heaven (#23691) Summary: <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot. But native crashes were (and still are) much harder to diagnose. ..Until now :D I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help. The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr). I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly. I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling. After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it. In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`. The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym. I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code. Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost! Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice. I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above. [iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them. [General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode. Pull Request resolved: https://github.com/facebook/react-native/pull/23691 Reviewed By: fkgozali Differential Revision: D14276366 Pulled By: cpojer fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
2019-03-13 05:24:07 +03:00
#else
RCTFatalException(exception);
#endif
}
return folly::none;
}
}
}