Affected User Tracking – The Easy Way To Find Out Who, What, Why and When!

Are software errors ever a good thing? I don’t think so, do you? If only your code just worked, and worked for everybody, life would be so easy. Your application users are real people, and when seeing error counts creeping upwards it can be hard to make the relation between the numbers and the people who are experiencing these issues. So we wondered how to make sure that your users were at the heart of your error reporting activities and today we’re launching Affected User Tracking.


What if you could not only see error occurrences in Raygun – but which of your users those errors affected? What if you could view each user and which errors they experienced? What if you could contact those users and notify them of a fix? Well, we’ll show you how to do all of this and more with this powerful new feature.

Who was affected?

Get a full list of affected users who have experienced crashes and errors with your application. We’ll display who has experienced problems alongside how many times.


What errors did they experience?

Click on each user to view the errors they experienced, so you can see when and why they happened, with all the information you need to fix the issues they experienced, before further users are affected.


Contacting users to give amazing experiences

notifysmallWe’ve all seen those pop up notifications when you experience a crash. Would you like to send a crash report? Well, no, not really, as no doubt it’ll just disappear into a black hole, never to be seen again. Raygun allows you to flip this customer experience completely on it’s head. When you are notified of a particular user experiencing a particular error, imagine how surprised and delighted a customer might be to receive a notification to say that you saw they experienced a problem and have deployed a fix. Perhaps even offer a discount voucher or incentive to apologise.

Software developers may not be customer facing the majority of the time, but delivering these types of customer experiences can make all the difference when competing in the highly competitive software market and can lead to increased customer satisfaction, sales and profits. You can choose to contact each user individually or send out a bulk email to all users that were affected by a particular issue. It’s easy.

It’s available right now

You can set this up right away! You’ll find Affected User Tracking located in the application sidebar as well as on each error details page for error groups where specific users were affected.


See the links for information on how to set up Affected User Tracking in your application, including PHPJavaScriptNode.jsJavaRailsASP.NetWPFWinRTWindows PhoneXamarin.iOSXamarin.AndroidAndroidPython and iOS.

Share this post

Discover causes of common Python exceptions

Following our recent post on Java exceptions, it’s time to look at several exception types that frequently occur in Python code, and how Raygun can assist you in diagnosing the cause of them.

Exceptions in Python are well-supported, and have been since Python 1.5 when proper exception objects were introduced (replacing string exceptions which were deprecated in 2.5). Python 2.6 introduces the ‘as’ syntax when one or more (as a tuple) exception types can be defined to be caught by a certain except block. This makes it simple to port 2.x code to Python 3.

All of the following exceptions are subclasses of Exception and are included in the standard library, which you can subclass yourself to your own types, and are descriptive of the cause in your code. This is used as part of the identity we create when grouping your exceptions intelligently, among other techniques.

Without more ado, here’s a list of python exceptions you’ll frequently encounter, and how Raygun’s Python provider can assist in debugging them.


This represents the action of referencing or assigning to an attribute that doesn’t otherwise exist – the classic null reference. For whatever reason certain parameters which are expected to have a value in the happy case will frequently not at runtime, which causes this exception to be raised.

The official Raygun provider for Python, Raygun4py, will present the backtrace that resulted in the AttributeError, the message will tell you what attribute was the cause, and the upcoming local variables feature will enable you to see the exact state in each frame. This allows you to pinpoint the cause of the error right after you are notified by email.


ValueError will be raised by a function when one of its parameters is of a value that is invalid – an example being divide(numerator, denominator) where 0 is passed in as the second param. As above you can see the offending variable in the error message in the Raygun dashboard, and its value in the local variables throughout the stack (crucially where it comes from and if it gets mutated in some way).


This very common exception will be raised when a certain operation is performed on an unexpected type. If this occurs in a web context due to malformed user input (especially critical in a REST API) the exception may be buried within a log file. It is critical to use an error tracking service like Raygun to ensure you are notified in a timely manner and have all the data needed to debug the exception and push a fix quickly.


When unit testing, AssertErrors will be raised by the unittest(2) module when a unit test fails. You may have your unit tests run by a build server (or service like Travis), and being notified by email that a build has failed often works well. Most likely your tooling will give you a huge text dump of the build log, which you need to manually sift through as tests fail.

Raygun allows you to extend this pattern by sending exceptions as well as raising them during the build process – you get notified by the exact tests that fail with their stack trace. In combination with the deployments feature (with GitHub integration for viewing the actual source code) visualizing regressions between builds is easy and allows you to pinpoint how committed code may have broken the build.

Begin your Raygun trial now

If you’d like to begin integrating a world-class exception tracking solution into your Python code, you can start your 30-day free trial here, no credit card needed. Got questions? Let us know in the comments below and we’ll get back to you pronto (we have great support from real humans). Until next time, keep frying those exceptions!

Share this post

NodeJS web frameworks and capturing errors

So you’re just about to start your sweet new NodeJS project? Awesome! Let’s be friends. Since you’re just starting out, you probably haven’t thought about exceptions yet, have you? No worries – I won’t tell anyone. Let’s have a look at how the raygun4node module integrates with a few of the NodeJS web frameworks you’ll most likely be looking at.


The almost-defacto framework for building web applications in NodeJS, ExpressJS makes it easy to integrate with the Raygun, you simply use:

Place it at the bottom of your middleware definitions and you’re away laughing.


Hapi is a lightweight library that focuses on reusable code and less on writing configuration code. Again, it’s super simple to integrate Raygun into Hapi’s workflow:


Building REST Apis? There’s a module for that! And it’s brilliant. Meet Restify. But catching errors you ask – here you go!


Koa is a newish framework from the guys who did ExpressJS with a whole bunch of new thinking. They made dealing with errors pretty easy. Because we have no routes, this sample throws two errors, but that won’t happen normally though of course!

But I’m feeling hardcore and want to deal with raw HTTP?

Boom, nice work! You’re probably pretty good at NodeJS already, so you don’t really need help right? Well I’m going to anyway! The easiest way to capture errors without a framework is using the domains feature of NodeJS. You simply wrap your app up in a domain and deal with the error event.

Interested in trying professional-grade error tracking? All of these insights and more are available with Raygun, so start your free 30-day trial now, no credit card needed. Happy exception blasting!

Share this post

Top 4 Java exceptions Raygun can help fix

There are a bunch of Java exceptions that are common to all code bases, and frequently occur at both compile time when implementing, and runtime when your application is in the wild. This last case is crucial to have visibility around – most developers may use a logging framework, or perhaps a hand-rolled notification system. The advantage of using a real error tracking service is huge. Here are some of the most common Java exceptions, and how Raygun can capture these at runtime and help you find the source of the bug, leading to reliable software and happy end users.


Tony Hoare’s billion-dollar mistake of including ‘null’ in a modification to the Algol language must still be taken into account when dealing with the type system in Java (you will of course note that it’s a legit failure state, which can be handled in safer ways in languages like Rust). The act of accessing an uninitialized variable, or one that has been deliberately set to null, blows up strongly-typed code at runtime as the type system can’t provide any guarantees for the object (by design). Knowing when your code attempts to use null variables is crucial. If you’re in a web context, frequently a third-party API may return some error state in response to a request, and the variables which would have otherwise been set would be null.

(I know – it’s Knuth, not Hoare, but close enough. The hat sells it.)

Seriously though, Raygun will capture every instance of your code attempting to use null objects, and report the stack trace so you can pinpoint the issue. The Raygun4Java provider also allows you to set custom data, so you can provide the state of relevant variables, allowing you to easily diagnose NullPointerExceptions on your production hardware from your local machine.


This exception type (and others in its family) can be thrown when invalid file access occurs, which is most likely to occur when implementing a local application when debugging is easier. Networking errors can also result in this exception being thrown, which is more critical when this happens in production web applications or services.

It is particularly interesting how often connections can fall down at the network layer – for instance, database query timeouts. These can be quite frequent, especially if your code is running in a public cloud with noisy neighbours, or in general if resource contention is a factor. Raygun will capture instances of these exceptions, giving you insights as to how often these are occurring over time, which would be very difficult to see from view log files.

Concurrent (threading) exceptions

Exceptions like InterruptedException are raised when your thread receives an interrupt while it is executing. You must catch this or return it to be handled higher up (depending on whether it makes sense for the current method to do so). These and similar concurrent exceptions may only start to appear under heavy load in production when contention for threading resources becomes a factor. It is important to use a tool like Raygun that can track and group these sensibly, so you can see how often and when these are occurring as their transient nature can be quite difficult to reproduce locally.


This is one you should be throwing in your own code, so that at runtime when a method receives invalid input you can throw an appropriately typed exception. Raygun can show instances of these, and as in the null pointer case, you can attach custom data to see the particular invalid arguments that were passed in (for instance, zero as the denominator for a Divide() method). This would be invaluable when developing anything that accepts user input, for instance a web API or service, mobile app, or desktop application.

Get started with Raygun now

Interested in trying professional-grade error tracking? All of these insights and more are available with Raygun, so start your free 30-day trial now, no credit card needed. Happy exception blasting!

Share this post

Error Monitoring in Test Driven Development

In the modern development shop, back and front end developers are expected to do a lot more than they ever did before: tooling, unit testing and even functional testing. At the same time, the release cycles are reduced and the number of feature requests are increasing. Is it possible to maintain quality and performance with all these new burdens?

The answer is yes. It is possible, and some teams are already doing it. How?

Great tools allow more to be done with less effort, especially when QA and operations teams are transitioned or reduced and the responsibilities of development starts growing quickly. But a tools first approach can quickly become a problem.

Tools solve nothing if the perception of how they will be adopted is wrong

For example, jumping on an analytics tool as a method to track errors is not only a misuse of the technology but has some serious technical and operational limitations. In this case, there will be long delays before errors can be identified, and the developer who needs to use the analytics tool will not have ownership.

Despite this, log analysis tools are often pitched as a way to advance the team, help in unit testing and handle bugs without additional work.

Both of these processes take quite a bit of energy. They are at the front end of development and on the first line of defense for bugs, but often developers don’t realize that effort spent here saves time and angry team members at their desk later.

For front-end developers working on new functionality, unit tests are not only annoying, but they also take up brain-cycles. While the premise around test-driven development is fantastic, it’s also a mental distraction, requiring the creativity to both code the feature and develop the methods of testing.


Detailed tests should be written for each function/class, but they require a great deal of coding and thinking about test cases. If done correctly, this can be a very complex process because developers naturally have a tendency to write tests so they pass—which obviously drives release managers crazy!

Test driven development (TDD) is not new, but it is as an addition to functional testing. If developers code unit tests, and then selenium code when features are complete, they have now crossed three different activities. Not surprisingly, this may require testing efforts that exceed the amount of time spent on development.

The key to performance in this scenario is to keep both tools and log analysis. Asking developers to do the testing and the QA team to facilitate and automate is extremely beneficial for catching bugs and responding to them more quickly. And by reducing the complexity of the test cases, time will be saved in the long run. One way to reduce complexity is to pick tools that have a great interface, notify you instantly on commits or releases and allow you to quickly prioritize issues without doing anything special.

Error Monitoring

Error monitoring—a line of code that never changes and is put in every error handling block—is a great example of this type of tool. The cloud interface associated with error monitoring identifies critical errors and pushes those errors out to users instantly. Common errors, the ones that pop up in every release but have little impact, will be low priority whereas a net new error type would be highlighted.

There is no way to avoid the burden that necessary testing early in the delivery pipeline puts on the developers. The issue must be addressed but not by choosing tools on a whim or making an existing tool do the job. Picking purpose-built tools that back up the increasing testing load will reduce the complexity of testing cases and allow developers the freedom to code rather than spend their time contemplating how they will catch and respond to bugs.

Raygun is the answer.

Want to get started with Raygun’s FREE trial and discover a new way to work? It’s easy, sign up in seconds.

Share this post

Architecting Your Software Errors For Better Error Reporting

Already you have to worry about unit testing and basic error catching, and now you’re expected to create a broader exception handling design? Most teams see individual developer errors as personal, but in reality, they impact everyone. Error blocks may belong to individual developer code, commits and releases, and for the most part are considered only on the developer level, but for development teams to improve over time, developers need to architect their errors and get serious about error reporting.

Architecting Your Errors

What does “architect your errors” mean? This phrase simply describes a technique for individual developers to more quickly identify errors. Their errors are then integrated with all other errors so they can be viewed on an application-by-application basis rather than developer-by-developer.

This method not only helps developers reduce error response time, but also improves the software delivery pipeline by pushing the entire team to make the move to continuous integration and delivery (CI/CD). They can do that because the release automation process now knows way more about code quality than it ever did before. Stopping releases that don’t pass, and letting the others deploy straight to integration labs, or even production.

It’s true that your coding and testing styles are very personal, but when team members and customers are screaming about issues, identifying their location and the responsible developer means applying the fix much faster. And, as we know, fast fixes are the key to reducing computer rage and increasing Dev Team happiness!


Developing the System

Embracing the architecting process all at once will be easier than rolling out changes one at a time. With that in mind, we have five tips for developing your architecting system.

  1. Establish naming conventions and standard error messages across the team. Align error names with business logic and naming conventions from other systems. Naming should not be unique to any one developer;
  2. Always include version information and details about releases or commits in your errors;
  3. Identify the feature and/or unit test associated with the error;
  4. Create a standard for exception handling and clearly communicate this to the entire team; and
  5. Leverage error monitoring tools to quickly spot and respond to errors.

In addition to your personal architecting, the team as a whole should design a platform to collect, report and release wide all errors on the application. Rather than trivial errors, your focus should be on net new or critical errors.

Using the System

Be warned, though, architecting your exception handling processes can be just as challenging and addicting as any code block! This is especially true in terms of exception design patterns and testing your testing. Eventually this can feel a bit odd, but also rather fun when combined with a cloud-based error monitoring system like Raygun that provides a dashboard-like feel. You’ll experience your exceptions like never before!

Just like your coding style, your exceptions are personal, but the possible bugs they create are not. Taking proactive action on how your exceptions are thrown, what information is gathered from them and how they correlate with the team’s exception processes will save both time and stress.

At first, you won’t feel comfortable highlighting your exceptions. But as overall delivery and response to application bugs improves, you’ll be happy you were the champion of architecting your errors!

Want to see what Raygun can do to revolutionise the way you handle software errors and error reporting? Try a FREE trial of Raygun today!

Share this post

Writing High Performance .NET Code

Recently our CEO John-Daniel Trask was invited to give a presentation at the 2015 dotnetConf. This was a little different from your everyday and traditional format of a conference, with all sessions being held virtually and viewers tuning in from all over the world. This two-day event includes more than 16 hours of content on subjects such as ASP.NET 5, .NET Core, Roslyn, learnings from running large scale websites, and more!

John-Daniel talked briefly about Raygun, what problems it solves for developers and then detailed how you can write high performance .NET code. Slides for the talk are also available below.

Watch the video below

View the presentation slides here

If you’re needing to increase results or write high performance .NET code yourself, we hope these handy tips are useful to you. Don’t forget, Raygun has support for all major programming languages and platforms including .NET. Try it for FREE with our no obligation trial.

Share this post

How to monitor panics with Raygun for Golang

Today I’m going to show you how to use our new official Raygun4Go provider created by Jakob Anders and Christoph Rahles from Käuferportal


Raygun is an error reporting service for logging errors in your applications and providing you with all the information you need to solve them. Get valuable awareness of how well your published/deployed applications are really doing now with Raygun for Golang.

Basic usage


This tutorial assumes you know the basics of Golang. To keep things simple, I’m trying out Raygun4Go in the hello world test program described here. To get started, install the Raygun4Go package using go get in a terminal:

To ensure full panic coverage in your Golang program, we recommend setting up Raygun4Go to be one of the first steps in your main method (or in webservers, your request handling method). Open the .go file containing the main method (in my case, hello.go), and then add an import for Raygun4Go.

Set up

Now in the main method, create a raygun client object by calling the New method which requires an application name, and your Raygun API key that you want to use for this app. The application name can be whatever you want, and the API key is shown to you when you create a new Application in your Raygun account, or can be viewed in your application settings.

In the spirit of good error handling, lets also check that the raygun client creation didn’t cause an error, and print it to the console if it did.

The last step required to set up Raygun4Go is to defer to the HandleError method.

Try it out

To test this out, call panic any where after the defer, then run the program to see the message and stack trace show up in your Raygun dashboard:


Manually sending messages

The raygun client object also has a CreateError method for manually sending an error message to your Raygun dashboard. This is great for reporting that something has gone wrong, but a panic doesn’t need to be invoked – for example you may want to report errors from within an error handler, or send a message when a bad status code is returned from a web request. The error report sent to Raygun will even include the stack trace.


The raygun client object returned from the New method has several chainable features as follows:

  • Silent(bool) If set to true, errors will be printed to the console instead of being sent to Raygun.
  • Version(string) Sets the program version number to be sent with each error report to Raygun.
  • Request(*http.Request) Provides information about any http request responsible for the issue.
  • User(string) Sets the user identifier, e.g. a name, email or database id.
  • Tags([]string) Sets a list of tags which can help you filter errors in your Raygun dashboard.
  • CustomData(interface{}) Sets additional information that can help you debug the problem. (Must work with json.Marshal).

Here is an example of using a few of these features:

And here is the full listing of my hello.go program:

Try it yourself

If you want awareness of the issues occurring in your go programs, try Raygun4Go using the simple steps above. If you don’t have an account yet, start a free Raygun trial here, no credit card required.

Share this post

Emmet and CSS: The forgotten part


If you’re new to Emmet coding a.k.a Zen Coding I would recommend that you read my previous article Speed up your markup with Zen Coding / Emmet. It will give you a good introduction and a detailed walk through of the real power of Emmet. In short, Emmet is the developer tool you can’t live without. That may sound like a big promise, I know, but that’s how much I love it. The greatest power is the HTML part of Emmet, but this post will focus more on what it can do with CSS.

Emmet Vs code snippets

This could maybe be the confusing part. Why would I use Emmet when my code editor already provides me with good snippets? Maybe you even have your own set of super spacey magical costume snippets with jet engines that you would offer your leg to keep. Well, that would be silly, we still need our legs even though we are developers. First of all, it’s not this or that, it’s this and that. With most code snippets you have to hard code or it will only give you the property, not the value. For example

This maybe seems like a small improvement, but for something you do a lot it makes a big difference.

Useful Emmet rules

Maybe not surprising but there are many CSS rules, so I won’t be able to write them all. I’ve collected the ones I use most. After you have seen the following examples you might think “holy batman”, that’s hard to remember. Don’t worry, first of all you’ll get it quickly. Second of all, Emmet has a little clever search function that will pick the closest rule. So the best way to learn is to experiment. I think these examples will give you a good idea of the structure.


I suggest that you have a look at the full list of rules at Emmet’s cheat sheet. Maybe you will find something you didn’t think of. Emmet and CSS is great but as I mentioned before, the fire of Emmet is the HTML part so please grab your sword, go to Speed up your markup with Zen Coding / Emmet and become a real ninja. And remember, don’t forget your old snippets 😉

Share this post

Pluralsight Course For Raygun Now Available!

We’re big fans of educational training website Pluralsight here at Raygun, so as the story goes, we approached our friend Filip Ekberg about doing a Pluralsight course on Raygun. Soon afterwards we heard he’d recorded the tutorial sessions and submitted it for review! We’re pleased to announce the course is now live and accessible on the Pluralsight website. Check it out here.


We’d obviously like to thank Filip for all his hard work putting the course together and for his blog post about the course going live. We hope to see additional courses in the future, for example “Getting started with Raygun in PHP”, if this is something you would like to see, let us know! The Pluralsight course just released covers the following subject areas:


  • Handling Errors? Why?
  • Why Raygun?
  • Demo: Setting up Your Raygun Account
  • Summary

Raygun in Desktop Applications

  • Introduction
  • Demo: Raygun in a Console Application
  • Demo: Raygun in a WPF Application
  • Demo: Raygun in a Windows Forms Application
  • Demo: Raygun in a Windows Service Application
  • Summary

Raygun in ASP.NET

  • Introduction
  • Demo: Raygun in ASP.NET MVC
  • Summary

Raygun with Xamarin

  • Introduction
  • Demo: Raygun in Xamarin
  • Summary

Administration and Integration

  • Introduction
  • Demo: Integrating with Hipchat
  • Demo: Integrating with GitHub
  • Summary

See full course details

This course provides a great resource for people that want to get a detailed introduction to Raygun, and don’t forget, we have a FREE trial available to help you get started.

Share this post