Provide new functionality equivalent of the old `CascadeMode.StopOnFirstFailure`

Is your feature request related to a problem? Please describe.

Hi there. Thank you for your amazing work.

This has been discussed a few times before — #1576, #1558 — but to be honest I’m not really satisfied with Jeremy’s answer; and I’ll present my reasoning in just a bit.

I have dozens of validators for different types in my project, and for nearly all of them, I want the following logic:

• At property level, I want the first failure to stop the validation chain; so that there is at most one validation error per property.
• At object (validator) level, I want the validation to continue for all properties, regardless of whether one or more of them fails; so that there are at most as many validation errors as there are properties in the object.

This is a very common style.

To achieve this, I either have to repeat .Cascade(CascadeMode.Stop) for EVERY SINGLE PROPERTY which is tedious and verbose, or I can use the deprecated StopOnFirstFailure either at validator class level (CascadeMode = CascadeMode.StopOnFirstFailure) or in the global configurations (ValidatorOptions.Global.CascadeMode = CascadeMode.StopOnFirstFailure;). But of course StopOnFirstFailure is marked as deprecated, and as such causes an annoying warning, plus Jeremy has advised against using it and argues that it’s better to repeat .Cascade(CascadeMode.Stop) for every single property instead. I strongly disagree. The whole point of setting validator-level or global configurations, in general, is to not have to explicitly repeat that configuration in each specific case.

The most important thing to remember is that what the StopOnFirstFailure option DOES is in fact perfectly legitimate, the only problem it ever had was its confusing NAME, which is what eventually led to it being marked as deprecated. But I would argue it shouldn’t have been, it should’ve just been renamed. Because again, wanting one failure per rule chain is a perfectly legitimate and common requirement, and if you want this behavior across all your validators, as I do, ideally you should be able to specify this configuration in one place and not have to repeat it over and over again. That’s the whole point of global configurations.

Describe the solution you’d like

I’d propose the following: Either rename Stop and StopOnFirstFailure to phrases that more accurately describe their behavior, with their behavior remaining intact. Sure, this is a breaking change, but it’s a small one anyway, and it would once and for all solve this age-old confusion over these two options. I’m confident that the people who’d be happy about this change would certainly outnumber those who’d be unhappy and would wish the old names back.

But if you absolutely don’t want any breaking change: Resurrect StopOnFirstFailure and remove the [Obsolete] attribute on top of it. I know you can suppress the warning in your code manually, but I’m sure you’d agree that it’s really ugly. More importantly, if the whole point of marking StopOnFirstFailure as deprecated is to make people aware of its difference with Stop — which it seems to be because Jeremy has stated multiple times that it’s not going to be removed — then you can also do that in its summary. Marking it as deprecated is not semantically correct, and it sends the wrong message, by seeing the word “obsolete” in the tooltip when hovering over it, one would think that that means it shouldn’t be used at all, or even worse, that it’s going to be removed in future versions; neither of which is true in the case of StopOnFirstFailure. So, that’s why I believe StopOnFirstFailure is not really “deprecated” in any meaningful sense. The only thing wrong with it is its name, which is not sufficient reason to mark it as deprecated.

Additional Context

And once again, I’m not the first person to have been bothered by this:

Here by @zoinkydoink:

for what its worthy, I think you should rename it to something better, dont deprecated it because there should be a way to do it at validator level, just with a better name.

Here by @dave-allen-cko:

We were using CascadeMode.StopOnFirstFailure in a many of our projects (at global and sometimes validator level), but this has now been deprecated. We have ways to reproduce the old behavior, but finding it a little verbose using the new CascadeMode options.

Here by @buvinghausen:

I think the ability to fail fast is good but typically speaking I want to give the user feedback on all the failed properties at once what I don’t like is giving them multiple lines of feedback per property. As such the stop on first failure set at the validator level was exactly what I wanted. Now I have to add the cascade call to every single rule for which is tedious and verbose when you’re dealing with so many properties.

etc.

[jsabrooke]

Thanks @JeremySkinner, I’ll start on the code at some point soon. And sure, I’m happy with your naming suggestions etc.

And thanks @AradAral, I was hoping you’d agree with the changes actually seeing as you raised the issue!

This made me laugh way harder than it should have! 😂

I just thought it would be a perfectly reasonable option for Jeremy to take 😃

[aradalvand]

I’d like to thank both @JeremySkinner for his openness and willingness to actually consider this despite being initially hesitant, I found his approach to conversation to be very productive, and of course @jsabrooke for their absolutely phenomenal work, without them, this wouldn’t have been done.

Thank you!