mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Valentin Shergin
57dd48b246
Summary: Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue). Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core. This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling. I hope that will give us much more informative crash reports. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D23787492 fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
67 lines
1.9 KiB
C++
67 lines
1.9 KiB
C++
/*
|
|
* 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.
|
|
*/
|
|
|
|
#include "EventTarget.h"
|
|
|
|
namespace facebook {
|
|
namespace react {
|
|
|
|
using Tag = EventTarget::Tag;
|
|
|
|
EventTarget::EventTarget(
|
|
jsi::Runtime &runtime,
|
|
jsi::Value const &instanceHandle,
|
|
Tag tag)
|
|
: weakInstanceHandle_(
|
|
jsi::WeakObject(runtime, instanceHandle.asObject(runtime))),
|
|
strongInstanceHandle_(jsi::Value::null()),
|
|
tag_(tag) {}
|
|
|
|
void EventTarget::setEnabled(bool enabled) const {
|
|
enabled_ = enabled;
|
|
}
|
|
|
|
void EventTarget::retain(jsi::Runtime &runtime) const {
|
|
if (!enabled_) {
|
|
return;
|
|
}
|
|
|
|
strongInstanceHandle_ = weakInstanceHandle_.lock(runtime);
|
|
|
|
// Having a `null` or `undefined` object here indicates that
|
|
// `weakInstanceHandle_` was already deallocated. This should *not* happen by
|
|
// design, and if it happens it's a severe problem. This basically means that
|
|
// particular implementation of JSI was able to detect this inconsistency and
|
|
// dealt with it, but some JSI implementation may not support this feature and
|
|
// that case will lead to a crash in those environments.
|
|
assert(!strongInstanceHandle_.isNull());
|
|
assert(!strongInstanceHandle_.isUndefined());
|
|
}
|
|
|
|
void EventTarget::release(jsi::Runtime &runtime) const {
|
|
// The method does not use `jsi::Runtime` reference.
|
|
// It takes it only to ensure thread-safety (if the caller has the reference,
|
|
// we are on a proper thread).
|
|
strongInstanceHandle_ = jsi::Value::null();
|
|
}
|
|
|
|
jsi::Value EventTarget::getInstanceHandle(jsi::Runtime &runtime) const {
|
|
if (strongInstanceHandle_.isNull()) {
|
|
// The `instanceHandle` is not retained.
|
|
return jsi::Value::null();
|
|
}
|
|
|
|
return jsi::Value(runtime, strongInstanceHandle_);
|
|
}
|
|
|
|
Tag EventTarget::getTag() const {
|
|
return tag_;
|
|
}
|
|
|
|
} // namespace react
|
|
} // namespace facebook
|