Support ModeStatelDictionary.AddModelError overload that does not require ModelMetadata arg

[lencharest]

The ModeStatelDictionary.AddModelError overload that takes 3 arguments uses the 3rd arg (ModelMetadata) only in very limited circumstances. Nevertheless, the 3rd arg may not be null. In my case, I'm forced to instantiate a ModelMetadata that I know is useless.

Please support a 2 argument variation that omits the ModelMetadata for the common case where the caller knows that the exception (2nd arg) is not one of the types that get special treatment:

public void AddModelError(string key, Exception exception) { ... }

[Eilon]

Hi @lencharest , I'm guessing the reason for this is that generally using exceptions for model state errors doesn't do much aside from flagging the field as invalid -- the exception text isn't even used. Only a few specific exceptions that are "known to be safe" (such as FormatException) are used to produce actual error messages - and even for those, the Message of the exception isn't used.

As such, to add a model state error with a specific error message, it's probably best to call AddModelError(string key, string errorMessage).

Having said all that, I think it's certainly possible to add the overload you're asking about, but I want to make sure that it's actually what you want first 😄

[lencharest]

Actually, I'm using the 3 arg version of AddModelError because message strings aren't rich enough for my needs. I'm treating the exception object as a property bag (in the sense that the exceptions exist to hold contextual information about a validation error and are never thrown). What would be ideal is something like

public void AddModelError(string key, object info) { ... }

with a corresponding object Info property added to ModelError.

Background: I've written an action filter that performs validation of primitive action parameters that are decorated with custom attributes. For example:

public void Get([ValidIpAddress, FromQuery] string ipAddress) { ... }

where ValidIpAddressAttribute is a custom validation attribute.

My action filter calls ValidIpAddressAttribute.IsValid(ipAddress). If the action parameter is invalid, it then stores an error on the model state by calling modelState.AddModelError(parameterName, contextInfo, metadata), where contextInfo is an instance of a custom exception.

The upshot of all this is that I know that the metadata argument passed to AddModelError will never be used because I am never passing an instance of FormatException or OverflowException as the 2nd argument. Therefore, I'd like to avoid having to create the metadata instance at all.

[dougbu]

@lencharest one workaround is to create one ModelMetadata instance and store that instance in a static field somewhere.

How are you using the context information later? MVC keeps the exceptions around but doesn't use them anywhere (after handling the FormatException and OverflowException cases. And, custom validations that add error strings to the ModelState are the norm.

[lencharest]

@dougbu, the motivation for this issue is to avoid creating an object I know I don't need.

Error strings aren't rich enough for my needs. The context info is used during serialization of a validation error response. I have a formatter that iterates over the ModelStateDictionary and builds an error response from it. My error schema requires more information than I can get from a single string.

[dougbu]

@lencharest 🆗 my previous workaround wasn't helpful. Why use ModelStateDictionary versus, say, a separate dictionary mapping the same keys (or whatever keys needed) to the additional information?

[lencharest]

@dougbu, I want to leverage the same model validation framework that is built in to ASP.NET.

[dougbu]

@lencharest as I understand it, you're using custom validators for some errors and they add additional information to the ModelStateDictionary which is later handled in a custom formatter. My suggestion was for those validators to place the extra information somewhere else and make it (and ModelStateDictionary) available to your formatter. Please let me know if I'm missing something.

[lencharest]

@dougbu, my custom validators are invoked inside the OnActionExecuting method of a custom ActionFilterAttribute. To use another object as a container for rich validation info, I'd need to inject that object into either the attribute or the ActionExecutingContext passed to the method. I don't think the former is possible (using the DI framework provided by ASP.NET). The latter could probably be achieved by stashing the container in ActionExecutingContext.HttpContext.Items, but implementing that cleanly seems like just as much work as what I've already done.

[Eilon]

Ok we should just add the requested overload that takes in the exception so that it's available later in the pipeline.