Add and use QM_OR_ELSE_WARN_IF/QM_OR_ELSE_NOTE_IF/QM_OR_ELSE_LOG_IF macros
Categories
(Core :: Storage: Quota Manager, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox90 | --- | fixed |
People
(Reporter: janv, Assigned: janv)
References
Details
Attachments
(11 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1708643 - Rename orElseFunc argument to fallback in QM_OR_ELSE_REPORT definition; r=#dom-storage
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
In case the orElseFunc
just propagates some kinds of errors, we output both a warning and then an error. This will cause a split in the stacks during processing despite the fact that errors are propagated.
The original patch for the warning macros has this comment:
// XXX In case the orElseFunc just propagates some kinds of errors, we will
// output both a warning and (then) an error. This is not too bad, but maybe
// also not the nicest thing. However, addressing this would require two steps:
// first determining whether an error of expr is going to be handled in some
// way, and then possibly passing it to that handler.
That is probably quite hard to implement, because the goal there is to report either one WARNING or one ERROR (if I understood it correctly).
However it would be quite easy to check the result of orElseFunc
and either report an error or warning depending on new result produced by orElseFunc
.
So, it would work like this:
- if there is no failure,
QM_OR_ELSE
just moves the success over. - If there's a failure and
orElseFunc
returnsOk
, a warning is reported and no error is reported by the enclosing QM_TRY - If there's a failure and
orElseFunc
propagates the error, an error is reported and then another error is reported by the enclosing QM_TRY
This is still not ideal solution because instead of reporting just one WARNING or ERROR, we will report two ERRORs, but that is only a cosmetic issue (one extra ERROR event).
Actually, it quite makes sense because the error is "re-thrown" in orElseFunc
And we probably need a new name for the macro after these changes.
Assignee | ||
Comment 1•4 years ago
|
||
(In reply to Jan Varga [:janv] from comment #0)
However it would be quite easy to check the result of
orElseFunc
and either report an error or warning depending on new result produced byorElseFunc
.So, it would work like this:
- if there is no failure,
QM_OR_ELSE
just moves the success over.- If there's a failure and
orElseFunc
returnsOk
, a warning is reported and no error is reported by the enclosing QM_TRY- If there's a failure and
orElseFunc
propagates the error, an error is reported and then another error is reported by the enclosing QM_TRYThis is still not ideal solution because instead of reporting just one WARNING or ERROR, we will report two ERRORs, but that is only a cosmetic issue (one extra ERROR event).
Actually, it quite makes sense because the error is "re-thrown" inorElseFunc
And we probably need a new name for the macro after these changes.
Checking the result of orElseFunc
is not optimal either because it would cause wrong ordering of QM_TRY
events.
I figured out something else. We basically need a new method Result::orElseIf
and then QM_OR_ELSE_WARN_IF
macro.
The idea is that orElseIf first checks if the error code should cause a fallback (using a predicate), if not, the error is just propagated.
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D114739
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D114842
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D114843
Assignee | ||
Comment 5•4 years ago
|
||
Depends on D114844
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D114843
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D114844
Assignee | ||
Comment 8•4 years ago
|
||
Depends on D114846
Comment 9•4 years ago
|
||
Comment on attachment 9221510 [details]
Bug 1708643 - Add QM_OR_ELSE_LOG and QM_OR_ELSE_LOG_IF macros; r=#dom-storage
Revision D114936 was moved to bug 1701346. Setting attachment 9221510 [details] to obsolete.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D114846
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
Depends on D115131
Assignee | ||
Comment 12•4 years ago
|
||
Depends on D115150
Assignee | ||
Comment 13•4 years ago
|
||
Depends on D115151
Assignee | ||
Comment 14•4 years ago
|
||
Depends on D115152
Assignee | ||
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
bugherder |
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3b6fea1b0638
https://hg.mozilla.org/mozilla-central/rev/2962c68b44e5
https://hg.mozilla.org/mozilla-central/rev/a2ef523fd8b4
https://hg.mozilla.org/mozilla-central/rev/fa200b5fb647
https://hg.mozilla.org/mozilla-central/rev/cb1824657a65
https://hg.mozilla.org/mozilla-central/rev/8ac77d476c0e
Description
•