ladybird/Libraries/LibJS/Runtime/Completion.h

327 lines
11 KiB
C
Raw Normal View History

LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
/*
* Copyright (c) 2021, Andreas Kling <andreas@ladybird.org>
2023-01-27 21:33:28 +00:00
* Copyright (c) 2021-2023, Linus Groh <linusg@serenityos.org>
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Optional.h>
#include <AK/Try.h>
#include <AK/TypeCasts.h>
#include <AK/Variant.h>
#include <LibJS/Runtime/ErrorTypes.h>
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
#include <LibJS/Runtime/Value.h>
namespace JS {
#define TRY_OR_THROW_OOM(vm, ...) \
({ \
/* Ignore -Wshadow to allow nesting the macro. */ \
AK_IGNORE_DIAGNOSTIC("-Wshadow", \
auto&& _temporary_result = (__VA_ARGS__)); \
if (_temporary_result.is_error()) { \
VERIFY(_temporary_result.error().code() == ENOMEM); \
return (vm).throw_completion<JS::InternalError>((vm).error_message(::JS::VM::ErrorMessage::OutOfMemory)); \
} \
static_assert(!::AK::Detail::IsLvalueReference<decltype(_temporary_result.release_value())>, \
"Do not return a reference from a fallible expression"); \
_temporary_result.release_value(); \
})
#define MUST_OR_THROW_INTERNAL_ERROR(...) \
({ \
/* Ignore -Wshadow to allow nesting the macro. */ \
AK_IGNORE_DIAGNOSTIC("-Wshadow", \
auto&& _temporary_result = (__VA_ARGS__)); \
if (_temporary_result.is_error()) { \
auto _completion = _temporary_result.release_error(); \
\
VERIFY(_completion.value().has_value()); \
VERIFY(_completion.value()->is_object()); \
VERIFY(::AK::is<JS::InternalError>(_completion.value()->as_object())); \
\
return _completion; \
} \
static_assert(!::AK::Detail::IsLvalueReference<decltype(_temporary_result.release_value())>, \
"Do not return a reference from a fallible expression"); \
_temporary_result.release_value(); \
})
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// 6.2.3 The Completion Record Specification Type, https://tc39.es/ecma262/#sec-completion-record-specification-type
class [[nodiscard]] Completion {
public:
enum class Type {
Empty,
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
Normal,
Break,
Continue,
Return,
Throw,
};
ALWAYS_INLINE Completion(Type type, Optional<Value> value)
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
: m_type(type)
, m_value(move(value))
{
VERIFY(type != Type::Empty);
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
if (m_value.has_value())
VERIFY(!m_value->is_empty());
}
Completion(ThrowCompletionOr<Value> const&);
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// 5.2.3.1 Implicit Completion Values, https://tc39.es/ecma262/#sec-implicit-completion-values
// Not `explicit` on purpose.
ALWAYS_INLINE Completion(Value value)
: Completion(Type::Normal, value)
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
{
}
ALWAYS_INLINE Completion(Optional<Value> value)
: Completion(Type::Normal, move(value))
{
}
ALWAYS_INLINE Completion()
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
: Completion(js_undefined())
{
}
Completion(Completion const&) = default;
Completion& operator=(Completion const&) = default;
Completion(Completion&&) = default;
Completion& operator=(Completion&&) = default;
[[nodiscard]] Type type() const
{
VERIFY(m_type != Type::Empty);
return m_type;
}
[[nodiscard]] Optional<Value>& value() { return m_value; }
[[nodiscard]] Optional<Value> const& value() const { return m_value; }
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// "abrupt completion refers to any completion with a [[Type]] value other than normal"
[[nodiscard]] bool is_abrupt() const { return m_type != Type::Normal; }
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// These are for compatibility with the TRY() macro in AK.
[[nodiscard]] bool is_error() const { return m_type == Type::Throw; }
[[nodiscard]] Optional<Value> release_value() { return move(m_value); }
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
Completion release_error()
{
VERIFY(is_error());
VERIFY(m_value.has_value());
return { m_type, release_value() };
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
}
private:
class EmptyTag {
};
friend AK::Optional<Completion>;
Completion(EmptyTag)
: m_type(Type::Empty)
{
}
bool is_empty() const
{
return m_type == Type::Empty;
}
Type m_type { Type::Normal }; // [[Type]]
Optional<Value> m_value; // [[Value]]
// NOTE: We don't need the [[Target]] slot since control flow is handled in bytecode.
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
};
}
namespace AK {
template<>
class Optional<JS::Completion> : public OptionalBase<JS::Completion> {
template<typename U>
friend class Optional;
public:
using ValueType = JS::Completion;
Optional() = default;
Optional(Optional<JS::Completion> const& other)
{
if (other.has_value())
m_value = other.m_value;
}
Optional(Optional&& other)
: m_value(move(other.m_value))
{
}
template<typename U = JS::Completion>
2022-10-17 00:06:11 +02:00
explicit(!IsConvertible<U&&, JS::Completion>) Optional(U&& value)
requires(!IsSame<RemoveCVReference<U>, Optional<JS::Completion>> && IsConstructible<JS::Completion, U &&>)
: m_value(forward<U>(value))
{
}
Optional& operator=(Optional const& other)
{
if (this != &other) {
clear();
m_value = other.m_value;
}
return *this;
}
Optional& operator=(Optional&& other)
{
if (this != &other) {
clear();
m_value = other.m_value;
}
return *this;
}
void clear()
{
m_value = JS::Completion(JS::Completion::EmptyTag {});
}
[[nodiscard]] bool has_value() const
{
return !m_value.is_empty();
}
[[nodiscard]] JS::Completion& value() &
{
VERIFY(has_value());
return m_value;
}
[[nodiscard]] JS::Completion const& value() const&
{
VERIFY(has_value());
return m_value;
}
[[nodiscard]] JS::Completion value() &&
{
return release_value();
}
[[nodiscard]] JS::Completion release_value()
{
VERIFY(has_value());
JS::Completion released_value = m_value;
clear();
return released_value;
}
private:
JS::Completion m_value { JS::Completion::EmptyTag {} };
};
}
namespace JS {
struct ErrorValue {
Value error;
};
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
template<typename ValueType>
requires(!IsLvalueReference<ValueType>)
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
class [[nodiscard]] ThrowCompletionOr {
public:
ALWAYS_INLINE ThrowCompletionOr()
2022-10-17 00:06:11 +02:00
requires(IsSame<ValueType, Empty>)
: m_value_or_error(Empty {})
{
}
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// Not `explicit` on purpose so that `return vm.throw_completion<Error>(...);` is possible.
ALWAYS_INLINE ThrowCompletionOr(Completion throw_completion)
: m_value_or_error(ErrorValue { throw_completion.release_error().value().value() })
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
{
}
// Not `explicit` on purpose so that `return value;` is possible.
ALWAYS_INLINE ThrowCompletionOr(ValueType value)
: m_value_or_error(move(value))
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
{
if constexpr (IsSame<ValueType, Value>)
VERIFY(!m_value_or_error.template get<ValueType>().is_empty());
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
}
ALWAYS_INLINE ThrowCompletionOr(ThrowCompletionOr const&) = default;
ALWAYS_INLINE ThrowCompletionOr& operator=(ThrowCompletionOr const&) = default;
ALWAYS_INLINE ThrowCompletionOr(ThrowCompletionOr&&) = default;
ALWAYS_INLINE ThrowCompletionOr& operator=(ThrowCompletionOr&&) = default;
ALWAYS_INLINE ThrowCompletionOr(OptionalNone value)
: m_value_or_error(ValueType { value })
{
}
// Allows implicit construction of ThrowCompletionOr<T> from a type U if T(U) is a supported constructor.
// Most commonly: Value from Object* or similar, so we can omit the curly braces from "return { TRY(...) };".
// Disabled for POD types to avoid weird conversion shenanigans.
template<typename WrappedValueType>
ALWAYS_INLINE ThrowCompletionOr(WrappedValueType&& value)
2022-10-17 00:06:11 +02:00
requires(!IsPOD<ValueType>)
: m_value_or_error(ValueType { value })
{
}
[[nodiscard]] bool is_throw_completion() const { return m_value_or_error.template has<ErrorValue>(); }
[[nodiscard]] Completion throw_completion() const { return error(); }
[[nodiscard]] Value error_value() const { return m_value_or_error.template get<ErrorValue>().error; }
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
2022-10-17 00:06:11 +02:00
[[nodiscard]] bool has_value() const
requires(!IsSame<ValueType, Empty>)
{
return m_value_or_error.template has<ValueType>();
2022-10-17 00:06:11 +02:00
}
[[nodiscard]] ValueType const& value() const
requires(!IsSame<ValueType, Empty>)
{
return m_value_or_error.template get<ValueType>();
2022-10-17 00:06:11 +02:00
}
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
// These are for compatibility with the TRY() macro in AK.
[[nodiscard]] bool is_error() const { return m_value_or_error.template has<ErrorValue>(); }
[[nodiscard]] ValueType release_value() { return move(m_value_or_error.template get<ValueType>()); }
Completion error() const { return Completion { Completion::Type::Throw, m_value_or_error.template get<ErrorValue>().error }; }
Completion release_error()
{
auto error = move(m_value_or_error.template get<ErrorValue>());
return Completion { Completion::Type::Throw, error.error };
}
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
private:
Variant<ValueType, ErrorValue> m_value_or_error;
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
};
template<>
class [[nodiscard]] ThrowCompletionOr<void> : public ThrowCompletionOr<Empty> {
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
public:
using ThrowCompletionOr<Empty>::ThrowCompletionOr;
};
ThrowCompletionOr<Value> await(VM&, Value);
2023-01-27 21:33:28 +00:00
// 6.2.4.1 NormalCompletion ( value ), https://tc39.es/ecma262/#sec-normalcompletion
inline Completion normal_completion(Optional<Value> value)
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
{
2023-01-27 21:33:28 +00:00
// 1. Return Completion Record { [[Type]]: normal, [[Value]]: value, [[Target]]: empty }.
return { Completion::Type::Normal, move(value) };
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
}
2023-01-27 21:33:28 +00:00
// 6.2.4.2 ThrowCompletion ( value ), https://tc39.es/ecma262/#sec-throwcompletion
Completion throw_completion(Value);
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 20:46:51 +01:00
}