Change addError method to public and virtual#423
Conversation
It can be useful to add one error string to all the records of an domain, directly from a service class, therefore it needs to be public. Sometimes it is also useful to change its behavior just like the other addError methods, therefore adding virtual
|
Hi @wimvelzeboer — thanks again for this PR. We've been discussing it among maintainers. The use case (e.g. applying a single non-field error across all rows from outside a domain subclass, such as from a service) makes sense. One concern raised internally is consistency: today fflib_SObjects exposes several protected helpers that apply the same kind of operation to every record in the bag (not only addError(String)). If we only promote addError(String) to public, callers can attach object-level errors from outside the hierarchy but still cannot use the same visibility for the closely related APIs, e.g.: addError(Schema.SObjectField field, String message) Proposal: extend this PR (or a follow-up commit on the same branch) so that the same "bulk mutator" family is aligned with addError(String) — at minimum public virtual on the field-level addError overload and on clearField / clearFields, with virtual kept where it already exists so domain subclasses can still override behavior the same way as for addError(String). If you're willing to update the PR along those lines, we can take another pass for review. Thanks for contributing. |
It can be useful to add one error string to all the records of a domain directly from a service class, therefore it needs to be public.
And it is also useful to change its behaviour just like the other addError methods, therefore adding virtual
This change is