react-native-macos/Libraries/Core/NativeExceptionsManager.js

109 строки
2.7 KiB
JavaScript
Исходник Обычный вид История

/**
* 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.
*
* @flow strict-local
* @format
*/
'use strict';
import type {TurboModule} from '../TurboModule/RCTExport';
import * as TurboModuleRegistry from '../TurboModule/TurboModuleRegistry';
export type StackFrame = {|
column: ?number,
file: ?string,
lineNumber: ?number,
methodName: string,
collapse?: boolean,
|};
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
export type ExceptionData = {
message: string,
Move React error message formatting into ExceptionsManager Summary: # Context In https://github.com/facebook/react/pull/16141 we imported `ReactFiberErrorDialog` unchanged from React. That implementation was not idempotent: if passed the same error instance multiple times, it would amend its `message` property every time, eventually leading to bloat and low-signal logs. The message bloat problem is most evident when rendering multiple `lazy()` components that expose the same Error reference to React (e.g. due to some cache that vends the same rejected Promise multiple times). More broadly, there's a need for structured, machine-readable logging to replace stringly-typed interfaces in both the production and development use cases. # This diff * We leave the user-supplied `message` field intact and instead do all the formatting inside `ExceptionsManager`. To avoid needless complexity, this **doesn't** always have the exact same output as the old code (but it does come close). See tests for the specifics. * The only mutation we do on React-captured error instances is setting the `componentStack` expando property. This replaces any previously-captured component stack rather than adding to it, and so doesn't create bloat. * We also report the exception fields `componentStack`, unformatted `message` (as `originalMessage`) and `name` directly to `NativeExceptionsManager` for future use. Reviewed By: cpojer Differential Revision: D16331228 fbshipit-source-id: 7b0539c2c83c7dd4e56db8508afcf367931ac71d
2019-07-31 12:28:40 +03:00
originalMessage: ?string,
name: ?string,
componentStack: ?string,
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
};
export interface Spec extends TurboModule {
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
// Deprecated: Use `reportException`
+reportFatalException: (
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) => void;
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
// Deprecated: Use `reportException`
+reportSoftException: (
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) => void;
// TODO(T53311281): This is a noop on iOS now. Implement it.
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
+reportException?: (data: ExceptionData) => void;
+updateExceptionMessage: (
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) => void;
// TODO(T53311281): This is a noop on iOS now. Implement it.
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
+dismissRedbox?: () => void;
}
const Platform = require('../Utilities/Platform');
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
const NativeModule = TurboModuleRegistry.getEnforcing<Spec>(
'ExceptionsManager',
);
const ExceptionsManager = {
reportFatalException(
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) {
NativeModule.reportFatalException(message, stack, exceptionId);
},
reportSoftException(
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) {
NativeModule.reportSoftException(message, stack, exceptionId);
},
updateExceptionMessage(
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) {
NativeModule.updateExceptionMessage(message, stack, exceptionId);
},
dismissRedbox(): void {
if (Platform.OS !== 'ios' && NativeModule.dismissRedbox) {
// TODO(T53311281): This is a noop on iOS now. Implement it.
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
NativeModule.dismissRedbox();
}
},
reportException(data: ExceptionData): void {
if (NativeModule.reportException) {
Introduce NativeExceptionsManager.reportException API Summary: @public `reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated. In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`). This change is backwards compatible in two senses: 1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable. 2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`. Naturally, both fallbacks mentioned above discard `extraData`. NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback. While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes. Reviewed By: mmmulani Differential Revision: D16133080 fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
2019-07-16 19:30:52 +03:00
NativeModule.reportException(data);
return;
}
if (data.isFatal) {
ExceptionsManager.reportFatalException(data.message, data.stack, data.id);
} else {
ExceptionsManager.reportSoftException(data.message, data.stack, data.id);
}
},
};
export default ExceptionsManager;