(In reply to Simon Giesecke [:sg] [he/him] from comment #0) > Currently, the QM_TRY mechanism doesn't allow to distinguish between errors that cause the failure of some operation and warnings for non-standards situations that can be mitigated without failing the overall operation. The choice in the latter case is currently between not using QM_TRY (and, in particular, having no telemetry report) or reporting it like an error. While it's possible to identify these from the telemetry reports, it requires additional work for each analyzed build. It would be better to allow distinguishing this in the first place, ideally in a way that expresses the intent in code and allows to remove additional comments. I collected a list of areas which need to be addressed: 1. Conversion of existing (not necessarily all) NS_WARNING/QM_WARNING Currently, `QM_TRY` can only report errors, and in case of an error, it always `return` from a function. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/CacheParent.cpp#60 2. Missing warnings in cases when a specific errors is converted to a success This is not directly about `QM_TRY`, but rather about having a way to issue a warning which is reported to telemetry too. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/QuotaClientImpl.h#99 Another problem is that passing a generic (template) function to `orElse` makes it impossible to report concrete line in the source. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#671 3. Having no way to report harmless errors (like syntax errors) Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/IDBDatabase.cpp#372 4. Errors which don't cause overall failures and which should be reported as warnings only Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#7683 5. Special NS_ERROR_ABORT error which is used to cancel operations for example during shutdown and which propagates through multiple functions Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13745 which is called from: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13862 I think there are actually two things which `QM_TRY` currently lacks: 1. Log severity 2. Custom control flow (including now flow control)
Bug 1686191 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Simon Giesecke [:sg] [he/him] from comment #0) > Currently, the QM_TRY mechanism doesn't allow to distinguish between errors that cause the failure of some operation and warnings for non-standards situations that can be mitigated without failing the overall operation. The choice in the latter case is currently between not using QM_TRY (and, in particular, having no telemetry report) or reporting it like an error. While it's possible to identify these from the telemetry reports, it requires additional work for each analyzed build. It would be better to allow distinguishing this in the first place, ideally in a way that expresses the intent in code and allows to remove additional comments. I collected a list of areas which need to be addressed: 1. Conversion of existing (not necessarily all) NS_WARNING/QM_WARNING Currently, `QM_TRY` can only report errors, and in case of an error, it always `return` from a function. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/CacheParent.cpp#60 2. Missing warnings in cases when a specific errors is converted to a success This is not directly about `QM_TRY`, but rather about having a way to issue a warning which is reported to telemetry too. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/QuotaClientImpl.h#99 Another problem is that passing a generic (template) function to `orElse` makes it impossible to report concrete line in the source. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#671 3. Having no way to report harmless errors (like syntax errors) Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/IDBDatabase.cpp#372 4. Errors which don't cause overall failures and which should be reported as warnings only Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#7683 5. Special NS_ERROR_ABORT error which is used to cancel operations for example during shutdown and which propagates through multiple functions Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13745 which is called from: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13862 I think there are actually two things which `QM_TRY` currently lacks: 1. Log severity 2. Custom control flow (including now flow control)
(In reply to Simon Giesecke [:sg] [he/him] from comment #0) > Currently, the QM_TRY mechanism doesn't allow to distinguish between errors that cause the failure of some operation and warnings for non-standards situations that can be mitigated without failing the overall operation. The choice in the latter case is currently between not using QM_TRY (and, in particular, having no telemetry report) or reporting it like an error. While it's possible to identify these from the telemetry reports, it requires additional work for each analyzed build. It would be better to allow distinguishing this in the first place, ideally in a way that expresses the intent in code and allows to remove additional comments. I collected a list of areas which need to be addressed: 1. Conversion of existing (not necessarily all) NS_WARNING/QM_WARNING Currently, `QM_TRY` can only report errors, and in case of an error, it always `return` from a function. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/CacheParent.cpp#60 2. Missing warnings in cases when a specific errors is converted to a success This is not directly about `QM_TRY`, but rather about having a way to issue a warning which is reported to telemetry too. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/QuotaClientImpl.h#99 Another problem is that passing a generic (template) function to `orElse` makes it impossible to report concrete line in the source. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#671 3. Having no way to report harmless errors (like syntax errors) Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/IDBDatabase.cpp#372 4. Errors which don't cause overall failures and which should be reported as warnings only Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#7683 5. Special NS_ERROR_ABORT error which is used to cancel operations for example during shutdown and which propagates through multiple functions Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13745 which is called from: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13862 I think there are actually two things which `QM_TRY` currently lacks: 1. Log severity 2. Custom control flow (including now flow control)
(In reply to Simon Giesecke [:sg] [he/him] from comment #0) > Currently, the QM_TRY mechanism doesn't allow to distinguish between errors that cause the failure of some operation and warnings for non-standards situations that can be mitigated without failing the overall operation. The choice in the latter case is currently between not using QM_TRY (and, in particular, having no telemetry report) or reporting it like an error. While it's possible to identify these from the telemetry reports, it requires additional work for each analyzed build. It would be better to allow distinguishing this in the first place, ideally in a way that expresses the intent in code and allows to remove additional comments. I collected a list of areas which need to be addressed: 1. Conversion of existing (not necessarily all) NS_WARNING/QM_WARNING Currently, `QM_TRY` can only report errors, and in case of an error, it always `return` from a function. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/CacheParent.cpp#60 2. Missing warnings in cases when a specific errors is converted to a success This is not directly about `QM_TRY`, but rather about having a way to issue a warning which is reported to telemetry too. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/cache/QuotaClientImpl.h#99 Another problem is that passing a generic (template) function to `orElse` makes it impossible to report concrete line in the source. Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#671 3. Having no way to report harmless errors (like syntax errors) Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/IDBDatabase.cpp#372 4. Errors which don't cause overall failures and which should be reported as warnings only Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#7683 5. Special NS_ERROR_ABORT error which is used to cancel operations for example during shutdown and which propagates through multiple functions Example: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13745 which is called from: https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/dom/indexedDB/ActorsParent.cpp#13862 I think there are actually two things which `QM_TRY` currently lacks: 1. Log severity 2. Custom control flow (including no flow control)