Hi, helpful exception messages are very important, and ensuring that sufficient context is present is a good contribution to that. Thanks for pushing this forward!
When starting work on replacing uses of the deprecated ErrorResult::Throw(nsresult), I noticed that the existing error messages show a syntactical inconsistency. Some end with a period (.), some do not. To ensure a consistent presentation, we should define the preferred style for this, and apply it consistently. I think the options with their rationale are: 1. individual messages passed to Throw* should not end in a period, but should form a complete sentence otherwise and a period suffix might be added depending on how/where it is exposed 2. all individual messages passed to Throw* should end in a period, and they form a complete sentence; no additional period is ever added regardless of how they are exposed 3. individual messages passed to Throw* may or may not end in a period, depending on whether they form a complete sentence; no additional period is ever added regardless of how they are exposed I think either of the first two options should be chosen, with a slight preference for the first option. Are there other opinions on this? Maybe there are more options I didn't consider. Simon On Mon, Feb 10, 2020 at 3:23 PM Boris Zbarsky <bzbar...@mit.edu> wrote: > > Hello all, > > We just made some changes to how exception strings from ErrorResult get > formatted [1]. The changes apply to both the Throw* DOMException > methods and ThrowTypeError/ThrowRangeError. > > In the new setup, exception messages have "%s: " prepended to them, > where %s is replaced with one of: > > * "InterfaceName.methodName", when the exception is from a method cal. > * "InterfaceName.attrName getter", when the exception is from a getter > * "InterfaceName.attrName setter", when the exception is from a setter > * "InterfaceName constructor", when the exception is from a constructor. > > The idea is to give web developers a bit more context about what callee > failed. > > I have tried to go through existing message strings and remove > duplication of that information where it existed. > > The changes only affect exceptions thrown via the ErrorResult that > bindings pass to implementation methods. In particular, Promise > rejections via Promise methods (as opposed to throwing on the passed-in > ErrorResult) do not benefit from these changes; more work will need to > happen there. > > The changes also do not affect exceptions thrown via > ErrorResult::Throw(nsresult). As a reminder, this is deprecated and > people should switch to the methods that provide useful error messages. > > Please let me know if there are concerns around this change, suggestions > for further improvements, etc! > > -Boris > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613013 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
