The built in error handling in ASP.NET MVC is pretty poor. If there -controller- can't be found, we've got a 404. Errors? 500.

These then fallback to the ASP.NET error handling -> customErrors. Which means it -has- to goto an aspx or static page.

AND it does a 302 temp redirect .. before it hits the correct route.

AND it route (in the browser) is really poor. Especially with that nasty query string param, appended ...

---
So something like this would be really nice :=>

1) Allow the customErrors to call an MVC route .. and it's via ResponseRewrite (so the Url is unchanged, in the browser).

2) No more 302'ing to the error page. (refer to suggestion #1)

## Further Information##

Chat with Levi Broderick about this. He was chatting to myself and others on JabbR about this issue and some smart fix-suggestions :)

The current MVC validation could be described as a system where simple things are easy and everything else is dumbfounding because you fall off a conceptual cliff.

I appreciate that it tries to cater to the simplest possible solution where appropriate, but the current strategy of increasingly trying to solve slightly more difficult problems in each release isn't working out fast enough. I have written MVC sites since before 1.0 was released, but I still find myself reinventing much of it for every new MVC site.

If I could remake MVC validation, and I may take a crack as it's open source, I would aim for these capabilities:

* Provide validation logic explicitly and with clear CLR and JavaScript definitions, either by providing both in code, or by establishing logic piecemeal in objects that know how to turn themselves into CLR logic or JavaScript definitions. I am definitely not opposed to unobtrusive JavaScript, but the current validation descends into black magic. Roping together conditional validation in C# is easy enough given a few modules and some setup, but lord knows what the JavaScript will do in the end.

* Validate bound members given the model context. Being able to say that two passwords should match is not an unusual stretch.

* Define validation as a several-stage process and provide appropriate support for each stage. It is natural for a User object to know that it ought to have a username. It is similarly natural for something like an action to find out that the username is sadly occupied and to fail identically. Similarly, inside-out validation of model objects: this User validates; this User in the context of a view model may not validate because it's a duplicate user in a list of users.

* Gracefully handle conditional validation. On pages beyond scaffolded editing screens, there are sometimes many fields where some choices activate different paths or different sets of fields. It's not necessarily so much about choosing not to validate, but to be able to model the way the form logic is structured and deem some paths okay because they weren't taken. It's okay that the zip code for the shipping address was empty because the customer checked to ship to the billing address, or to use a saved shipping address.

* Like another suggestion said, make a distinction between the cause and the error, and make the error explicitly localizable by always work with a LocalizableError token class (or something). I have to dig up years old content from Phil Haack's weblog for any information about how this is supposed to work currently, or sift through the source code.

In short, I would build something that is designed from the start to be able to solve the hairiest commonly occurring validation problems. I am aware that this is not necessarily a simple problem, but the current solution isn't serving you very well if you deal in the sort of complex structures that some pages require. I have tried to provide concrete examples of these in-line.

Microsoft people like talking about the pit of success. People who want to be sensitive to handling validation correctly have to climb Mt. Success. I don't mind having to work out how the validation logic itself is going to have to work, but implementing it is many times more work.

I don't mean edit and continue. I mean "Web Site"-like watching-and-taking-notice recompiling. You could perform intrusive refactorings and it would smile and keep going.

I know that this is a large request that requires tipping the code base and architecture on end to make work, but it will be so worth it. Even if every page request took twice as long, you would still make up for the time spent transitioning in and out of debug mode. (And no, nothing says it'd have to be on all the time, so you could still test exactly as it'd work when published.)

* You could have this enabled only in development because that's the only place it'd be needed. It wouldn't be possible to publish with this mode turned on.

* Many of the components needed to do this are already there. The same file watcher that handles bundling notices when things have changed and recompiles (upon the first request).

* If the ASP.NET MVC structure is further unhinged from the ASP.NET pipeline, including HttpApplication, it wouldn't need to be completely evicted all the time. If this is completely impossible and you need to evict all of it all the time, doing so will still shave seconds off the code edit turnaround.

* If the technology exists to do this granularly, in the distant future, a variant could be used to do hot code loading; handling ongoing requests with the old version and gradually winding it down but taking new requests with the new version.

It's a hard problem and will require the right mixture of brilliance and duct tape, but productivity will skyrocket. Please at least think about it.

ASP.NET MVC lacks the ability to "deny" users and groups within its authorization framework.

Consider the scenario where a certain set of users or groups should have access to a resource *except* for a specific user or group.

A "DenyAttribute" could be added, or a "Deny" boolean property could be added to the existing AuthorizeAttribute. In both cases, a "deny" must take precedence over an "allow".

It's incredibly difficult for developers to "role their own solution" due to the complex interactions with the caching infrastructure. In addition, the existing AuthorizeAttribute cannot be extended with a base class since AuthorizeCore is not called when the AllowAnonymousAttribute is specified.

I love almost everything about the MVC framework. But I am continually tripping over, at great cost, a "feature" that gets in the way of how I generally use hidden input fields.

That feature is the way hidden field values are restored from a cache when a page is regenerated. I understand this is necessary to support field error handling, but when a hidden field is used simply as a "constant" to roundtrip data between post backs it causes all sorts of problems.

All I'd like is a simple optional switch in the Html.Hidden and Html.HiddenFor methods which would turn off that mechanism. That way I won't have to waste hours trying to duplicate the precise algorithms for generating tag names and ids needed to match the framework's expectations. Which is a royal pain in the butt, I assure you!