The reason a DOM operation failed.
dom::Error holds the details of a failed DOM operation, such as a DOM exception or a handle whose page is gone.
Passing dom::Checked returns a dom::Result you can inspect on failure:
if (!total) {
if (total.error().is_page_gone())
return;
Log(total.error().message());
}
constexpr Checked_t Checked
Pass to a DOM call to get a dom::Result holding the reason for a failure instead of an empty value.
Definition Error.h:299
Expected< T, Error > Result
The result of a DOM operation that can fail (either a T or a dom::Error).
Definition Error.h:277
Getting an Error
DOM operations return an empty value on failure instead of throwing C++ exceptions. Most code never needs dom::Error because operations on empty values fail safely without extra checks.
To inspect a failure, pass dom::Checked as an extra argument to receive a dom::Result holding either the value or a dom::Error.
When you've inspected the error and want to continue with an empty value, pass the dom::Result to dom::OrEmpty().
Kinds of Errors
Specific query methods identify each failure condition:
How you handle an error depends on its condition:
- Ignore page-gone errors in routine code. A page can navigate away at any moment, leaving nothing to report.
- Treat empty-handle errors as application bugs. They indicate that native code operated on an unassigned handle, a moved-from handle, or a lookup that found nothing.
- Inspect type() rather than message() in code. The message text is meant for human diagnostics and can change between releases, while type() returns stable dom::ErrorType values.
- Note
- An error you get through dom::Checked isn't logged by DOM diagnostics.
- See also
- dom::Checked, dom::Result, dom::ErrorType, dom::OrEmpty()