• Docs  › 
  • Clients

.NET Client

The Errordite .NET client is a lightweight .NET library, which plugs into your application and will respond to exception events, sending the details to the Errordite servers. The client is an open source project hosted on GitHub here. The guide below provides information on how to use the client.

1. Install

We recommend downloading the client from NuGet. Search for "Errordite" in the package manager or at nuget.org. If you prefer, you can download the binaries directly GitHub.

2. Configure

If you use NuGet to obtain the Errodite client, it will put a default configuration into your application config file. If not, you will need to add it in yourself. Note: the client binary name is different depending on whether it is the general version or a specialist version (e.g. for MVC3).

Sample configuration:

<configSections>
    <section name="errordite" type="Errordite.Client.Configuration.ClientConfiguration, Errordite.Client" />
<configSections>

<errordite token="**YOUR TOKEN HERE**" enabled="true"> 
    <dataCollectors> <!-- optional -->
        <dataCollector prefix="HttpContext" type="YourDataCollectorClassName, YourAssembly" />
    </dataCollectors>
    <sanitiseParams> <!-- optional -->
        <param name="Password" match="Contains" />
    </sanitiseParams>
    <unwrapExceptions> <!-- optional -->
        <exception typeName="System.Web.HttpUnhandledException" />
    </unwrapExceptions>
    <ignoreExceptions> <!-- optional -->
        <exception typeName="System.Web.HttpException"/>
    </ignoreExceptions>
</errordite>
    

The settings are described below:

  • Token
    The token for the application. Take this from your Applications page.
  • Enabled
    This should normally be true; set to false to stop sending to Errordite.
  • Data Collectors (optional)
    Data collectors allow you to send custom data with each exception in the form of a set of name-value pairs. To write your own data collector, just implement the Errordite.Client.Interfaces.IDataCollector and add it to your configuration.
  • Sanitise Params (optional)
    Some data shouldn't be sent to Errordite. For example you don't want an exception in a "login" form post to send the password to Errordite. To avoid this, just add the parameters you don't want to send here (you can specify an "Exact" match or a "Contains" match). HTTP form parameters, HTTP headers and items in the Exception's data dictionary honour this setting.
  • Unwrap Exceptions (optional)
    Some outer exceptions are such generic wrappers they provide no useful information. This section allows you to tell the client to send the inner exception (if it exists) instead. For example the System.Web.HttpUnhandledException is thrown from an ASP.NET application whenever an exception is unhandled. Another example is an exception-handling policy that demands all exceptions are wrapped in a particular custom exception.
  • Ignore Exceptions (optional)
    This section allows you to tell the client to ignore exceptions of a specific type. This setting respects inheritance.

3. Application Types

The differences between applications boil down to how the client can hook into exception events (HTTP Module, Action Filters etc), however it is worth noting that you can ignore all that and simply add the following line of code to your global error handling code.

ErrorditeClient.ReportException(ex);
    
  • ASP.NET MVC 3.0 or MVC 4.0
    For MVC 3/4, you can use the HttpModule that comes with the Errordite client. Simply add it to the HttpModules section of your web.config:
    <add name="ErrorditeModule" type="Errordite.Client.Mvc.ErrorditeModule, Errordite.Client.Mvc" />
                
  • ASP.NET MVC 2.0

    For MVC 2, the Errordite client library contains an exception filter (Errordite.Client.Mvc2.ErrorditeHandleErrorAttribute). We suggest creating a base controller and adding it to this controller to avoid having to add it specifically to each controller you create.

    [ErrorditeHandleError]
    public abstract class BaseController : Controller 
    {
        
    }
                

    Note that this will not cover exceptions thrown outside of an Action. For these you should also add an event handler to the HttpApplication.Context event and log the error from there.

  • ASP.NET Web Forms
    For Web Forms, add the following to the Application_Error event handler in global.asax.cs:
    protected void Application_Error(object sender, EventArgs e)
    {
        ErrorditeClient.ReportException(Server.GetLastError());
    }
                
  • General
    If you are using a different application type (console app / Windows Service / WPF etc.), already have exception handling code you want to plug in to, or for whatever reason the guidance above does not work for you, simply add the following line of code at the appropriate place.
    ErrorditeClient.ReportException(exception);
                

4. Errors in the client itself

Be default the client will fail silently, as we don't want it to itself generate exceptions. If you want to be notified of exceptions generated by the client you can provide a delegate to the client by passing it to the SetErrorNotificationAction method. For example:

ErrorditeClient.SetErrorNotificationAction(exception => Trace.Write(exception.ToString());
    

5. Sync or Async

By default, the Errordite client sends errors to Errordite asynchronously, to ensure that your application is not affected by the sending of the error. However, for applications that do not continue running after an error (e.g. a console app) this may not work as the process will have finished before the error is sent. In this case, you can specify synchronous sending when calling ReportException:

ErrorditeClient.ReportException(exception, true);
    

6. Customisation

As mentioned above, it is very simple to add custom DataCollectors to the client. If you wish to customise it further, just fork the source code! If it is a useful change, please give us a pull request so we can share it with everyone else.

Python Client

The Python client comes in two flavours: Django, and general-purpose Python. For full details of the clients, go to their GitHub repositories:

https://github.com/hugorodgerbrown/python-errordite

https://github.com/hugorodgerbrown/django-errordite

The libraries are available in pypi so can be installed using pip:

$ pip install errordite

or

$ pip install django-errordite

Ruby Client

The Ruby client is an open source library hosted on GitHub. It supports all major Ruby web frameworks and its Gem name is 'errordite'.

https://github.com/errordite/errordite-ruby

Please note: Documentation is on its way!

Send errors with JSON

Errordite can work with any language or technology. Simply post the JSON below to

https://www.errordite.com/receiveerror

If you would like to create a client plug-in for your favoured technology, we'd love to hear from you.

{
    "Token" : <string>,              //your application token, taken from Errordite
    "MachineName" : <string>,        //the machine that generated the error
    "Url" : <string>,                //the url of the request that caused the error if a webapp
    "UserAgent" : <string>,          //the user-agent from the request that caused the error if a web app
    "ContextData" : {                //bag of extra information about the context of the error occuring (web
        "PropertyName1" : <string>,  //request info, current user information, thread info, anything that 
            ...                      //might be useful)
        "PropertyName2" : <string>
    },
    "TimestampUtc" : <datetime>,     //the timestamp of the error (in UTC). Use ISO format yyyy-MM-dd hh:mm:ss
    "Version" : <string>,            //the version of your application when the error was raised
    "ExceptionInfo" : {
        "Message" : <string>,        //the message of the exception
        "Source" : <string>,         //the programmatic module that threw the exception 
                                     //(exact definition depends on technology stack)
        "ExceptionType" : <string>,  //the type of the exception
        "StackTrace" : <string>,     //the stack trace - formatting already done (i.e. indents & newlines)
        "MethodName" : <string>,     //the name of the method / function that threw the error
        "Data" : {                   //bag of extra information specifically related to *this* exception (rather 
            "PropertyName1" : <string>, //than its inner exception, for example). In many languages this may 
            ...                         //make no sense so just omit
            "PropertyName2" : <string>
        },
        "InnerExceptionInfo" : {     //recursive definition - same as ExceptionInfo above
            "Message" : <string>
            ...
        }
    }
}