How to handle missing files on MVC

What is your preferred way to handle hits to files that does not exist on your MVC app.

I have couple of web apps runing with MVC and they are constantly getting hits for files folders etc. that does not exist in the app structure.

Apps are throwing exception: The controller for path could not be found or it does not implement IController

I am trying to find out the best way to handle this.

I have 3 global routes on my global.asax file (see below) and at this point I am happy with that simple definition. I know if I added route definition for all controllers then I can add a definition to ignore the rest and handle these hits but if it will be possible to solve this problem without it, I do not want to add route definitions for each controller which I believe will flood the route definitions and also add a layer of maintenance which I don't like.

//Aggregates 2nd level
            routes.MapRoute(
                "AggregateLevel2",
                "{controller}/{action}/{id}/{childid}/{childidlevel2}",
                new { controller = "Home", action = "Index", id = "", childid = "", childidlevel2 = "" }
            );

            //Aggregates 1st level
            routes.MapRoute(
 开发者_如何学JAVA               "AggregateLevel1",
                "{controller}/{action}/{id}/{childid}",
                new { controller = "Home", action = "Index", id = "", childid = "" }
            );

            routes.MapRoute(
                "Default",
                "{controller}/{action}/{id}",
                new { controller = "Home", action = "Index", id = "" }
            );

---

In general, this is a valid error what you really want is to just not get a yellow screen of death.

The good news is, this is easy. In your web.config there is a tag called customErrors which probably (unless you changed it) has its mode set to remoteOnly. If that's the case, then the ASP.net custom errors handler will already deal with failed requests like that when the request doesn't come from localhost. If you want to see that behavior when you're on your dev box running locally, change the mode to "On".

The out-of-the-box behavior is to handle the error on controllers with the HandleError attribute applied. That works pretty well, and you can handle different errors differently by passing argumetns to that attribute. Normally, the attribute will simply output the error info to an Error.aspx view (by default located in your Shared folder) which simply spits out a flat statement that there was an error.

What behavior you are looking for might require you to change all that, in which case you would either create your own attribute that inherits from IExceptionFilter and do what you want to inside that.

Also, there's always the option of overriding the application's OnError either in global.asax or in a module, just like normal ASP.Net.

---

This may totally be the wrong way to do this but on my private site I have this in the global.asax file;

    protected void Application_Error(object sender, EventArgs e)
    {
        HttpException httpException = Server.GetLastError() as HttpException;
        RouteData routeData = new RouteData();

        routeData.Values.Add("controller", "Error");
        routeData.Values.Add("action", "Index");
        routeData.Values.Add("statusCode", httpException.GetHttpCode().ToString());

        Server.ClearError();

        IController errorController = new MyDomain.Controllers.ErrorController();

        errorController.Execute(new RequestContext(new HttpContextWrapper(Context), routeData));
    }

Then I have an error controller;

public class ErrorController : Controller
{
    public ActionResult Index()
    {
        //log out the error
        //string statusCode = RouteData.Values["statusCode"].ToString();

        return RedirectToAction("Index", "Home");
    }

}

So I always take the user back to my index page when there is an error.

This is only a private site so there are a lot of liberties I can take and my view is also that the less times you show a yellow screen, and the less information you give potential hackers, the better.