0 Comments

Available on NuGet

Including ELFAR (MVC) and ELFAR (Web API) in your web application is extremely easy.  However, if you're anything like me then you'll hate the idea of having to create two instances of the error log provider (assuming that you've referenced the same providers).  You can manually combine the files but, to save you the bother, I've done the leg work for you:

0 Comments

Erik Funkenbusch posted a question, on the ELFAR discussion board, regarding the logging of handled exceptions. He managed to figure out a solution and kindly posted it:

FYI, I found a solution that works pretty well.

try
{
    throw new NotImplementedException();
}
catch (Exception e)
{
    foreach (var filter in GlobalFilters.Filters)
    {
        if (filter.Instance is ErrorLogFilter)
        {
            var f = filter.Instance as ErrorLogFilter;
            f.OnException(new ExceptionContext(ControllerContext, e));
        }
    }
}

I actually took this one step further and created a .Log() extension method on Exception.

public static class ExceptionExtensions
{
    public static void Log(this Exception exception, ControllerContext context)
    {
        foreach (var filter in GlobalFilters.Filters)
        {
            if (filter.Instance is ErrorLogFilter)
            {
                var f = filter.Instance as ErrorLogFilter;
                f.OnException(new ExceptionContext(context, exception));
            }
        }
    }
}

Then you just need to use it as such:

try
{
    throw new NotImplementedException();
}
catch (Exception e)
{
    //...
    e.Log(ControllerContext);
}

However, there is an alternative solution: throw the exception and let ELFAR automatically handle it (Figure 1).

try
{
    throw new NotImplementedException();
}
catch (Exception)
{
    //...
    throw;
}
Figure 1

Update:

Erik responded with some good points:

Rethrowing the exception will result in an unhandle exception propogating to the client...The whole point is to handle th[e] exception, but log it so it can be investigated. I find this particularly useful with exceptions for external resources (Web requests, file access, etc..). There is no point in passing this on to the user if you can continue.

0 Comments

Introduction

Error Logging Filter and Route (ELFAR) for ASP.NET MVC was inspired by and based on the popular Error Logging Modules And Handlers (ELMAH) for ASP.NET utility. ELFAR retains the familiar ELMAH user interface but has been built to utilise the architecture of ASP.NET MVC. Unlike ELMAH, ELFAR is not driven by configuration and can be added to your website/web application with just 3 lines of code (usually in the Application_Start method):

var provider = new ErrorLogProvider();
GlobalFilters.Filters.Add(new ErrorLogFilter(provider));
RouteTable.Routes.Insert(0, new ErrorLogRoute(provider));
Figure 1

To access ELFAR, navigate to ~/elfar (where ~/ is the root directory of the MVC application).

Available on NuGet

ELFAR has 6 out-of-the-box error log providers:

Features

Once ELFAR has been added to your website/web application, you get the following features:

  • a web page to view a list of error logs
  • a web page to view the details of an error log, including a coloured stack trace
  • a view of the original yellow screen of death (where appropriate)
  • XML and JSON downloads of the error log
  • an RSS feed of the last 15 error logs
  • an RSS digest of daily error logs (limited to 900)
  • a CSV download of all error logs
    •    

Optional features

In addition, there are several optional features available:

  • Excluding unwanted exceptions
  • Restricting access to the ELFAR web pages
  • Email notification of errors   
  • Posting errors to Twitter
    •    

Resources

Further information can be found in the ELFAR Wiki.
Full source for ELFAR can be found at SourceForge.net (Subversion) or GitHub

0 Comments

Introduction

Recently, I started working on a large eCommerce website, implemented in ASP.NET MVC 3. I soon found that many of the forms in the site contained code similar to Figure 1, which I took an instant dislike to. The reason I dislike it is that “Action” doesn’t relate to anything (i.e. it isn’t an actual action name) and causes the URL to change when the form is submitted, so a URL like “/Blog/AddPost” will suddenly become “/Blog/Action”. Another side-effect is that the destination action method must specify explicitly the view name. I then discovered that it was to enable multiple submit buttons by using an implementation of the ActionNameSelectorAttribute class (Figure 2).

@using(Html.BeginForm("Action", null))
{
    <button name="Save">Save</button>
    <button name="Publish">Publish</button>
}
Figure 1
public class SubmitButtonNameActionNameSelector : ActionNameSelectorAttribute
{
    public override bool IsValidName(
        ControllerContext controllerContext,
        string actionName,
        MethodInfo methodInfo)
    {
        if(actionName.Equals(methodInfo.Name, StringComparison.InvariantCultureIgnoreCase))
            return true;

        if(!actionName.Equals("Action", StringComparison.InvariantCultureIgnoreCase))
            return false;

        var request = controllerContext.RequestContext.HttpContext.Request;
        return request[methodInfo.Name] != null;
    }
}
Figure 2
public class BlogController : Controller
{
    [SubmitButtonNameActionNameSelector]
    public ActionResult Save()
    {
        //...
    }
    [SubmitButtonNameActionNameSelector]
    public ActionResult Publish()
    {
        //...
    }
}
Figure 3

Previous technique

In other projects I’ve used a popular technique of binding the button’s name to a parameter name in the action method and then determining the button’s value, in order to branch to a different method. There are downsides to this approach but the main thing I dislike about it is that it’s quite messy. The ActionNameSelectorAttribute implementation allows for a cleaner separation of behaviour for each button.

Solving the problem

To circumvent the problems I have mentioned, I decided to use a variation of the SubmitButtonNameActionNameSelector implementation (Figure 4).

public class FormActionAttribute : ActionNameSelectorAttribute
{
    public override bool IsValidName(
        ControllerContext controllerContext,
        string actionName,
        MethodInfo methodInfo)
    {
        return controllerContext.HttpContext.Request[Prefix + methodInfo.Name] != null
            && !controllerContext.IsChildAction;
    }

    public string Prefix = "Action::";
}
Figure 4
public class BlogController : Controller
{
    [HttpPost, FormAction]
    public ActionResult Save()
    {
        //...
    }
    [HttpPost, FormAction(Prefix = "Action_")]
    public ActionResult Publish()
    {
        //...
    }
}
Figure 5
@using(Html.BeginForm())
{
    <button name="Action::Save">Save</button>
    <button name="Action_Publish">Publish</button>
}
Figure 6

Conclusion

By prefixing the button’s name there is no need to have “Action” as the form’s action (Figure 6), which means that the URL stays the same and there is no need to explicitly specify the view name.