See exceptions in your Slack integrations channel, annihilate them like a champ

We were stoked to see this tweet recently from @gnat who stumbled upon one of the killer features of Raygun:

Like all good software tools, Raygun is dogfooded internally to ensure the service nails the use cases for everyday software development. I can confirm that the Slack integration is pretty sweet, and is a critical part of our workflow. If you haven’t heard of it, Slack is a popular team chat service with rich support for messaging and team collaboration, which importantly allows third-party services your team uses (like Raygun) to post messages directly into your chat channels.

In this post I’ll be highlighting how we use this to streamline our development workflow and ensure the entire team is aware of exceptions when they occur, immediately.

A wild exception appears

Say you’re in the implementation phase, debugging locally. An exception is no big deal as you’ve got your debugger attached and the stack appears right in front of you:


The same applies during staging and testing, where your web server or mobile apps can output the stacktrace for your team to use. This completely falls down in production though, when exceptions like the one above fall into a black hole in a log file somewhere. You might have notifications set up using another service (which is also invaluable as a failsafe), but someone still has to find the offending machine or VM, remote in, diagnose the error, and begin work on a fix.

Tough call at 1am. And even when the heroic late-night fix is applied and your system is stable again, the cause and knowledge of the incident may remain with the one who had to triage it.

‘Raygun-Driven Development’

A much safer and more scalable approach is to have notifications sent to a team chat service like Slack, where exceptions are immediately visible to all. With all key services your devs, DBAs and QA integrated into one app, such as build servers, deployment services etc, team members have one centralized places they know to visit to get a constant stream of live updates for what actions are being applied to the system.

We’ve also got our source control (GitHub), build server (TeamCity) and deployment app (Octopus) all sending webhooks into Slack whenever someone takes an action. It winds up looking something like this:





Those are all from our development channel, where work-in-progress actions are recorded. With the ability to assign different webhooks to different channels, you can have your staging/beta environments send their events to a separate place from the mission-critical Production rooms. That way, if a message occurs in there, anyone watching knows it’s critical and to immediately click through to check out the stack trace, and alert the person with the most knowledge and chance of fixing it.

All of this takes place alongside discussions about the notifications as they occur – for instance, someone can @mention the person responsible, have a convo to decide on the best course of action, add a comment in Raygun, perhaps create an issue in GitHub, then develop, test, merge and deploy a fix, all while the whole team watches. Instant feedback, quality control and context for the entire team.

The real-time stream of webhooks as presented in the Slack channels becomes an invaluable timeline of events, which members can use to catch up on things they missed if they were away for a few hours/days while work continued.

Get started with Raygun and Slack

You only need two things to get the above slack integration working – a Slack account and a Raygun account. You can start your free 30-day Raygun trial here, and then link it with your Slack channels using the easy integration inside the app. Documentation for this is available here, but there’s only a couple of steps involved so it should Just Work.

Got any questions about how Raygun and Slack can work together to help your team build great software? Let us know in the comment form below!

Share this post

Programming is hard. Is there a problem with my brain?


“Now, navigate to a small folder in Terminal that you want your program to open with. Good, now it’s time to create your symbolic link in your PATH folder, BUT, before we do, let’s check your profile file by using nano ~/.bash_profile.”

My mind flicks through the catalogue of these words in my brain, I know I’ve learned them at some point, but I can’t piece them together into coherent instructions to myself before the teacher has moved on to the next topic.

‘What keyboard shortcut opens Terminal again? Command and Space – no wait that’s on a Mac’.

I grit my teeth and try not to think about how far behind the Treehouse instructor I am, as I scramble to open up Google and look up keyboard commands for the hundredth time. 

“I’m just not good at this”, I think to myself. “It must be my brain, I’m just not good with logic.”

This was meant to be an intro course – so why was I finding it so hard?

This scenario is not uncommon for me, whether I’m doing an online course, attending one IRL or having a colleague or friend teach me programming concepts. I always wind up feeling dumb, frustrated, and angry with myself and whatever poor soul is giving up their time to help me.

Most sessions end abruptly with a tight feeling in my throat and a rising swell building up in the back of my eyes before I declare that I’m not doing it anymore, and quit for the day. Sadly, most of the time I’m just a few stages away from completing a module, or making my app thing work, or having a break through – but it’s too late. The damage is done.

So I’ve been wondering, why is this? Why is learning to code so hard?

I think this is a not a straight forward question, with straight forward answers but I have several ideas as to why I am not finding coding an easy skill to acquire. I also asked the Twitter community for their thoughts, and received an overwhelming response:

So, with these gems of wisdom, these are my tops points for why I think programming is hard:

The ‘it’s so easy – I can’t believe you didn’t know that’ attitude

You know that thing where you just don’t get something – a maths equation, a programming problem, grammar in a foreign language, the political regime in South-East Asia…

And then some smarty pants comes along and glances over your shoulder, or interrupts you mid-sentence to say:

“Oh, but that’s easy”

Yeah that. That is why we can’t have nice things. Now you have to struggle through understanding the task at hand knowing that it should be easy, and everyone thinks so but you.

Possibly even worse though is:

“I can’t believe you didn’t know about the figure element in HTML – not that HTML is a real programming language anyway”

Seriously, it doesn’t matter that it’s not considered a ‘real’ programming language – it’s still a new skill that needs to be learnt. Trying new things is scary. It’s about being brave enough to be in the vulnerable position of not knowing and there’s nothing wrong with failure or uncertainty – in fact, it’s an important part of success.

And what’s the deal with that ‘I can’t believe you didn’t know that’ attitude in the tech industry? It’s impossible that someone can know every single idiosyncrasy about a programming language – they’re very complicated beasts. When did it become OK for us to belittle each other like this? Perhaps we’re just afraid we’ll get ‘found out’ for not knowing something.

It’s normal to find a new skill hard at first. As Jake the Dog once said, “Sucking is the first step to being sorta good at something”. And he is so right.



The ‘Left Brain/Right Brain’ argument

My favourite excuse to use when maths and programming problems are over my head:

“I don’t get it because I have a creative mind. Programming is logical and my brain just doesn’t work like that”

And while I so love to cling to this notion that I’m good at writing and painting because I’m a creative left-brained thinker, and I struggle with maths and programming type disciplines because they are primarily right brain based activities – there’s a lot of evidence to suggest that this is an outdated way of thinking.

The article ‘Debunking The Myths About The Programmer’s Brain‘ by Belle Beth Cooper investigates some of these common myths about how programmer’s minds work, and points out that “Our brain hemispheres are inextricably connected. Both sides are co-dependent and each takes a part in most thought processes”.

So, could it be that I’m just better at creative things because I’ve simply had more practise at them, due to believing I am naturally good at them? The saying comes to mind: ‘whether you think you can, or think you can’t – you’re right’.

Programming Is just hard, full stop

“Don’t believe anyone who tells you that learning to code is easy”

Probably summed up perfectly in this Tech Crunch article, while the recent push that ‘anyone can learn to code’ is doing amazing things for encouraging more people to join a previously seemingly unreachable industry, we could be going about it the wrong way by insisting that it’s an easy skill to learn.

As Kate Ray puts it in her article, ‘as a programmer, there is a limitless amount of stuff to learn’ – and a constant sense of inadequacy is sadly not uncommon for even those considered specialists in the field.

I think a better message to those who are just starting out might be that there is a LOT to learn, it might be challenging, but you CAN do – step by step. The following video about ‘How To Get Good At Anything’ explains that rather than trying to learn it all at once, and setting unclear goals like ‘I want to learn how to code’ – you need to be more specific about what you want to achieve, and break the tasks down into smaller tasks.

So maybe, instead of feeling sad that I can’t understand JavaScript yet – I’ll focus on just learning enough to make one part of my static blog interactive. Then, move onto the next step. And be prepared that I’ll probably be terrible at first, but that Jake the dog said that is totally OK.


Share this post

Raygun’s Secret Project – What is #ProjectNeutron?

There has been a bit of buzz flying around the development community of late as to what exactly #ProjectNeutron is. We’ve even gone to the effort of getting hoodies made (see below).

Now, the team do love a cosy hoodie whilst they are coding away on the Raygun application, they do, but they were particularly excited to pull on this rad piece of attire. Why? Project Neutron is why!

We’ve had many people asking us what this secret and classified project is, but for now we have to remain tight lipped. The team are at full capacity in the Raygun reactor and we’re going to have to leave them in there for a little bit longer (but not too long, we promise).

We’ll be sharing more details throughout August, so be on the lookout for updates. However if you want to be the very first to hear about what we have planned, simply pop your email into the box below and we’ll make sure you’re up to date!

Share this post

Raygun acquires Zing Design

Raygun acquires Zing Design

I’m excited to announce that Raygun has acquired Zing Design!

This is a very natural combination and the entire Raygun team is excited to have them joining us on our mission to help the world build perfect software.

Press Release

Raygun Limited (previously Mindscape Limited) has agreed to acquire Zing Design. The deal will involve key Zing Design staff & assets joining Raygun. Zheng Li, founder & CEO of Zing Design will be joining Raygun as Director of Product.

“This is an excellent outcome for Raygun and Zing Design” said Raygun Co-founder Jeremy Boyd. “We have been expanding our team rapidly in the last 12 months and to have Zheng Li & her team join Raygun will help accelerate our already high growth. We are especially excited by the emphasis on User Experience (UX) and customer centric thinking that Zheng and her team will bring to Raygun”

“My team and I couldn’t be more excited to be joining forces with Raygun. We’ve been working with the team at Raygun on early design work and recent marketing campaigns so we already know we work very well together” said Zing Design CEO, Zheng Li. “Being able to help direct such a loved product to even greater heights really excites me.”

The Zing Design team will be completing various contractual obligations over the near term before moving into the Raygun office and focusing entirely on their new roles on the Raygun team.

About Raygun Limited

Raygun, previously named Mindscape, is a leading global software tools provider based in Wellington, New Zealand. Mindscape changed its name to Raygun due to the success of their Raygun product – a crash reporting solution used by thousands of technology companies globally, including Microsoft, Auto Desk and Beats Music. Raygun has won numerous industry awards including the New Zealand Hi-Tech Innovative Software Product award in 2014 and the New Zealand Hi-Tech Start-up Company of the Year award in 2015. With customers in more than 100 countries, Raygun expanded the physical presence to the United States in early 2015 with offices in San Francisco.

About Zing Design Limited

Zing Design is a successful boutique digital UX design & marketing agency based in Wellington, New Zealand. Zing Design has led design and digital marketing campaigns for many high profile businesses including RaboDirect, Spark Foundation, Gareth Morgan Investments, Trade Me and many others. Zheng Li, the founder & CEO has been recognised as a Woman of Influence and is involved strongly with the design and technology communities in Wellington. Zheng also operates the Founders Exchange group for women in business.

Media Contact

Hilary Cook

Full Press Release: Raygun Acquires Zing Design (PDF)

Share this post

Missed our Raygun Webcasts? Watch them here!!

So, you’ve been tormenting yourself for weeks over those missed Raygun Webcasts. Naturally! You mixed the time up, busy at a badminton tournament or writing some code to manage that busy badminton calendar…

Well, now you have the chance to watch them over and over again. We’ve recorded both our webcasts and you can access them whenever you like. Wherever you like.

We understand you might have some questions, that’s ok. You can send us a quick email and we will get back to you as soon as possible.

In this introductory webcast, see how Russ uses Raygun during the development cycle to help debug errors and discover hidden problems from live production data.

WebcastImproving Your App Quality

WebcastImplementing Awesome Crash Reporting in Production Apps 


Not using Raygun yet, but desperately want to be? We get that!
Sign up for a FREE TRIAL. Easy.


Share this post

Setting Up Applications in Raygun For Optimal Error Monitoring

Error monitoring doesn’t have to be difficult and setting up Raygun is super simple, all it takes is to add a few short lines of code to your application and a few minutes of your time. But once you are reporting errors successfully, you might be wondering how best to set things up with all the other moving parts of your applications. Or as a first time user, you might be wondering what is an ‘application’ in Raygun exactly? Well, here we’ll detail a bit more about best practices when setting up applications in Raygun and how they correspond to your own applications.

What defines an ‘application’ in Raygun?

Well, each application you create in Raygun has a unique and separate API key, and it is the API key that tells Raygun where to send the error report when we receive it. Essentially your API key provides a way to group errors into containers, an easy way to organise and sort them. Your very own filing system for your errors to be stored under.

Add applications in Raygun for each language and platform

You have one product or ‘application’ as you might call it, so you only need one application in Raygun right? Well, this is not recommended. If you wanted to have one Raygun application monitoring errors across your entire stack then you certainly could, but using one Raygun application and one API key means that all errors from your product are then contained under a single Raygun application. By doing this, when viewing your Raygun dashboard you’ll see errors from all sorts of languages, platforms, environments and URLs – Not very useful, right? When looking for the highest priority issues or problems you care about the most it’s going to be far better to have things broken down into logical order and seperated from each other. But what is the best way to set this up?


Rather than have a single application and API key set up to handle all errors that are sent to Raygun, it’s best to set up multiple applications and have multiple API keys for each part of your application. For example, if your backend is built in Node.js, you want to monitor Javascript errors on your front end website and you also have an iOS and Android app to monitor, having multiple applications gives you the benefits of having errors sorted by programming language and platform as well as optimal grouping logic and custom setup options for each language.

What about environments?

Want to see errors specifically from dev, test and production environments? No problem! You can do this by creating additional applications and therefore having a separate API keys for each environment. Adding things like custom properties to error messages on the fly provides a clunky and notoriously bad user experience. Multiple applications set up to handle environments offers a far better user experience and makes sure everything is kept neat and tidy whilst per application notification rules allow you to be notified by environments you need to be (like production when things are affecting your users!). Separate applications can also be viewed on the Global Dashboard.


Built for teams

If your team is tasked with looking after specific parts of a large website, adding more applications allows you to use separate API keys for each section of your site, reporting errors into separate Raygun applications that your micro-teams can be made aware of.

Otherwise in this scenario you could add a tag to each error (see the documentation about this for our Javascript provider at then filter the dashboard by that tag. Pro-tip: If you want easy access to this particular filtered down dashboard. You can bookmark the dashboard in your browser after applying the filter as it’s added to the URL.

Still got questions about the best way to set up you applications? Feel free to hit the feedback link on the Raygun dashboard to get in touch with us!

Don’t have a Raygun account yet? It takes a few moments to get started with our free 30 day trial.

Share this post

@raygunio + 😀 = ❤️

Sometimes things can be said best with an emoji, especially when dealing with errors – the tiny faces and, uh, objects, somehow make the day better. And what better place can there be to put them than in your error tracking comments?

Raygun now has emoji support! Hit the : key on your keyboard and choose from a list of 937 emojis! There’s even a special non-standard one in there, see if you can spot it.

Screenshot 2015-07-20 10.25.58

To top off the emoji awesomeness, you can also mention users in comments. Chuck in an @ character and a list of your plan users pops up – pick the person you want to alert and hit enter. If you’ve been tagged in any comments, you’ll notice that you get highlighted, making it easier to scroll through and see the issues that relate to you.

Want emoji in your error tracking? Try Raygun today!

Share this post

Using Linters For Faster, Safer Coding With Less Javascript Errors

A few weeks ago I wrote an article about great Javascript debugging tips that many developers weren’t aware of. The article had a lot of traffic and was well shared. Today I will focus on how to discover bugs and Javascript errors before they even become a bug. Sounds odd? The magic we will discuss here is called a linter and I will explain what it is, why to use them and compare them so you know what will work best for you.


What is a linter?

Linters have been around for a long time and probably exist in one shape or form for all languages. A linter is basically a parser that parses your code and looks for mistakes. It’s a great way to save time, maintain quality and write safer code. You can plug linters in to your code editor or copy-past your code to a linting tool. Lint-ing your code is a great thing to do no matter what language you code with. You can even lint HTML, CSS and JSON. There are many different types, but here I will focus on the four most popular Javascript linters.

Workflow comparison

Example workflow WITHOUT linter.

  1. Write some code
  2. Save your code
  3. Refresh the page and wait for the page to load
  4. The inspector found an error
  5. You inspect the error and it says something like… “Uncaught SyntaxError: Unexpected identifier on line 43 file…”
  6. You think “that’s kind of a cryptic message”. You return to the code to see what’s actually causing the problem on line 43
  7. Ah, you missed a comma between your variable declarations
  8. You add the comma… var variable1 = 1, variable2 = 2;
  9. Then you save the project and walk yourself through the whole process again, thinking “wow, this is a bit time consuming. I really hope I didn’t miss a comma somewhere else”

Example workflow WITH linter

  1. Write code. In the meantime the linter tells you about your syntax errors.
  2. You fix your mistakes
  3. Save your code
  4. You smile and think “wow, this is the future”


Benefits of using a linter.

  1. Get instantly notified of your mistakes
  2. Save time
  3. Safer code
  4. You can stay focused on the hard part of your coding
  5. Better coding flow
  6. Obvious highlighting in your code
  7. Your team will follow the same coding style
  8. It’s just more fun. It’s like magic

Which Javascript linter should I use?

There’s a few of them out there so I’ll give you a quick walk through of some of them.

JsLint: Douglas Crockford is like the father of the Javascript linter. He started the development in 2002 with roles he well discussed in his book – Javascript the good parts. JsLint is his own project and he keeps on updating it by himself. JsLint is the oldest out of the ones mentioned here.

JsHint: Is a community driven open source project that started in 2010. It started as a fork of the JsLint project. Since more people are developing JsHint it’s been improving and changing more than JsLint. They removed some rules and added new ones that would better suit the way a Javascript developer codes today. JsHint is today a more flexible linter and it’s the most commonly used.

EsLint: Is open source and started in 2013. The founder says he love JsHint but found himself in need of a more pluggable linter. The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable. It ships with a basic set of rules to get started with, then it’s up to you what rules you want to change or implement. This is the linter for the person who needs to add and change linting rules. If you’re not one of those people, maybe one of the other three linters would be a better choice.

Jscs: Started 2013 and ships with 90 validation rules (or 120 according to their github), including presets from popular style guides. This is great so we don’t need to come up with our own style-guides over and over again. Here’s a list of presets Jscs provides.

  • Airbnb
  • Crockford
  • Google
  • Grunt
  • jQuery
  • MDCS
  • node-style-guide
  • Wikimedia
  • WordPress
  • Yandex

But, I still don’t know which one to use.

Well, maybe it’s easiest to just follow the bigger mass. This is the download history for the last month from 6th July 2015.

  1. JsLint: 38,210 downloads
  2. JsHint: 1,635,776 downloads
  3. EsLint: 363,212 downloads
  4. Jscs: 366,619 downloads

Let’s see who is using what…

Who is using JSLint?

¯\_(ツ)_/¯ I couldn’t find anything.

Ah, but who is using EsHint?

Again….. ¯\_(ツ)_/¯

Ah, but who is using JHint?

Mozilla     Wikipedia     Facebook     Twitter     Bootstrap     Disqus     Medium

Yahoo!     SmugMug     jQuery     PDF.js     Coursera     Adobe Brackets     Apache Cordova

RedHat     SoundCloud     Nodejitsu     Yelp     Voxer     EnyoJS     QuickenLoans     oDesk

Cloud9     CodeClimate     Pandoo TEK     Zendesk     Apache CouchDB

And who is using Jscs?

jQuery      Adobe     Bootstrap     AngularJS     Yandex     Wikimedia     Grunt

Ember.js     Ionic     Moment.js     TodoMVC      Famous     less.js     Goodvidio

Since there are heaps of code editors and a bunch of linters, I will focus on just one editor. Since I’m using Sublime Text 3 on Mac, this should give you a good demonstration. Don’t worry if you’re not a Sublime Text 3 user, I’m sure Google will be there for you to find information for other setups. With that said this guide may still be useful for you. Here’s how to install linters in Sublime Text.

Installing a pre installed linter like JSLint

JsLint is preinstalled with SublimeLinter so all you need to do to get started is…

  1. Make sure you’ve installed sublime package control.
  2. Install sublimelinter, which is the base package for the linters.
  3. Now. Restart Sublime and open a JavaScript file. Make sure you have some syntax errors in your code. Then hit save.
  4. You should now see something like this…

JsHint lint errors

Installing a NOT pre installed linter like EsLint

  1. Make sure you’ve installed SublimeLinter3 and it’s working.
  2. Install the linters you want. e.g cmd+shift+p and type sublimelinter-eshint
  3. As you can see all linters starts with sublime-linter-[linter name]Command pallete
  4. Once we have installed it in the editor we need to install it on on the computer. Sublime linter are using the node package manager so we have to install them as well.
  5. Open the terminal and type $npm install -g eslint
  6. Once that is installed you want to navigate to your project directory and type $eslint –init
  7. The prompt will now ask you how you want your linter to be set up. It will create a settings file you can change at any time.npm eslint set up questions
  8.  Now. Restart sublime and open a JavaScript file and make sure you have some syntax errors in your code. Then hit save.Sublime eshint

Linting tips

You’ll find all you need under Tools->SublimeLinter. Here are some good things to know.

I can see the lint dots but what do they mean?

They easiest way to find out is simple click somewhere on the line and in the bottom list of sublime you can see the message.

Lint modes

Two settings worth mentioning are Lint Mode->Load/Save and Lint Mode->Background

Load/save will lint your file every time you load and save. Background will instantly lint your file while your’re typing.

Tips if you’re using background mode

I prefer the background mode but without right settings it can be quite annoying when all colors are shifting constantly.

Longer delay time and weaker color settings make it much better. Open Sublimelinter-sublime.settings and change to following values.

  • mark_style: stippled underline
  • lint_mode: background
  • delay: 2
Color exapmle of SublimeLinter

EsLint is not showing all errors in Sublime

One difference between EsLint and JsHint is the presentation of lint errors. EsLint only shows the top error while JsHint shows all at once. Compare the pictures above and below. Without any further investigation I believe it is a Sublime thing since the demo on EsLints website shows all errors at the same time.

EsLint sublime linter

Jump between your lint errors

A really good feature I also want to mention is the jump-between-lint-errors feature.

Let’s say you have a bunch of lint errors, you can hit cmd+ctrl+a and you can navigate between the lint errors with your arrows keys. Pretty awesome when you are linting big chunks of code to find errors.Jump between lint erorrs

Get more help with debug = true

Debug is by default false but if you set it to true the linter will output all messages in the console. Pretty handy sometimes.


I hope the namings didn’t confuse you. I would expect to see something called EsHint in the future… or why not LintHint?

I hope you found this article useful, and if you still don’t know what linter to pick you can probably go for JsHint since it’s the most popular one, it’s well maintained and been around for a while.

No matter what linter you pick, the difference between using one and not using one is big. Bring some light to your work desk and have fun.

Discovering problems before they even become a problem is great. Fixing bugs is even greater but knowing what errors went live is invaluable. I can’t raise enough glasses for Raygun, the error tracking tool that keeps track of all errors your users experience.

I would also recommend you to read some of my previous articles on a similar topic.

And if you’d like to speed up your coding

Links and resources

Share this post

The difference between iOS Exceptions and Errors

As developers working with any language, it’s important to know what can go wrong in your code. This is a beginner’s overview of exceptions and errors in iOS – 2 different constructs that you’ll want to distinguish between.


In short, exceptions cause applications to crash if left unhandled. They generally occur when trying to perform an operation on an object incorrectly, such as using an out-of-bounds index to access an array item, or passing nil to a method that doesn’t accept it. In other words, they are caused by developer mistakes.

Unhandled exceptions in your published apps must be avoided at all costs. Your customers will not be pleased if your app crashes, and your business can suffer from it. If exceptions are so detrimental, then why do they exist? They are warnings to developers that a serious coding issue has occurred and needs to be fixed. They are expected to occur during development of you application, and provide information that will help you solve the issue before shipping your app.

Objective-C provides a single class to hold exception information called NSException. This class contains 3 key points of information:

  • name identifies the type of exception that has occurred. As mentioned above, there is only one exception class, rather than different classes to represent different problems – so the name property is used as the high level categorization. Some common exception names you may come across include NSInvalidArgumentException and NSGenericException. The main predefined cocoa exception names are defined in NSException.h.
  • reason is a short explanation of why the exception has been thrown. For example “+[Class Selector] unrecognized selector sent to class 0x10866fb88″.
  • userInfo is an NSDictionary of additional information that can help to debug the problem. I haven’t seen any use of this from exceptions thrown by the cocoa framework, it seems to be more used by developers throwing their own exceptions to provide values of properties and variables and so on.

Throwing and catching exceptions

You shouldn’t ever need to throw exceptions in you application, however they can be useful if you’re writing a library – be it for your app or for other developers. If someone calls a method in your library with invalid arguments, throwing an exception is a way of telling them they’re doing it wrong. In case you ever need to do this, exceptions can be created with the NSException class factory method shown below which takes the 3 key bits of information to help identify and debug the problem. The exception can then be thrown using the @throw directive:

Wherever possible, you should check or/and constrain arguments before calling methods to avoid them throwing exceptions. If in doubt, or if not possible, you can use @try @catch blocks to handle exceptions however appropriate.

In the @catch block above you can see a use for the NSException name property. By checking the name of the exception, you can handle different types of exceptions that may occur from the same operation in different ways. Using a @throw; directive inside a @catch block will cause the exception to be rethrown where it can be handled further up the calling chain. The @finally block at the end will run its code regardless of if an exception occurred. This is useful for cleaning up memory or anything else that you need to ensure is performed before exiting the method.

Exception reporting with Raygun

So I’ve been going on about making sure you avoid or handle exceptions before releasing your application, but is your published app really bug free? If you have a very complex code base or/and you use third party libraries that throw exceptions you’re unaware of, then probably not. Once your application is out there being used by your customers all around the world, it would be great to know whether or not there are still exceptions are crashing your application!

Awareness of exceptions in your published apps can be achieved by integrating Raygun4iOS into your application. This listens for exception signals that crash the application, and then sends the information about the crash to the Raygun cloud service. There you can see how often each exception occurs, how many users are being affected by them and all the information you need including the stack trace to fix the bug for the next release. Raygun4iOS can be installed either with CocoaPods, or manually – instructions can be found here. A single line of code is then used to enable unhandled exception reporting for your whole app:

If you want to know about an exception that you’ve handled in a @try @catch block, you can manually send the exception object with the Raygun reporter as follows:


Errors are used in quite a different way than exceptions. They don’t get thrown, and they don’t cause the application to crash. Instead, they are created to hold information about a failure, and then bubbled up through calling methods where it may be ‘handled’ in some way such as displaying a message to the user. Failures that result in errors being created can be considered common or even expected issues. A lot of the built-in cocoa errors are related to file system issues – such as files not being found, or running out of memory while writing. errors in iOS are represented by the NSError class which provides these 3 properties:

  • domain is a high level grouping of errors.
  • code is used to distinguish different types of errors within a domain.
  • userInfo is an NSDictionary containing additional information about the error.

The documentation here has more information about these 3 properties, including constants that you’ll commonly see used.

Working with errors

You may come across some methods that have a direct (NSError *) or indirect (NSError **) reference to an NSError as the last argument. This is how errors get passed up though method chains. An important thing to note is that methods with an indirect reference are expected to return NO or nil to indicate whether or not the operation was successful. You should always check this first to determine if an error has occurred before using the NSError object. Here is a simple usage example of checking an error.

With that in mind, make sure any of your methods that create errors can be used in the same way.

Also, make sure you either use existing domains and codes OR your own domain and codes – don’t mix and match an existing domain with your own code within the same NSError object.

Sending error information to Raygun

If you want to know about whether or not and how often certain errors are occurring in your published applications, you can do so by manually sending them with Raygun4iOS. Simply use the following code to send an NSError instance to Raygun. You can optionally send a list of string tags, or an NSDictionary of custom data to further help understand what’s happening within your app.


Exceptions are caused by programming faults, and must be fixed or handled. Errors are expected to happen from time to time and should be dealt with accordingly. Raygun can be used to get insight into your published applications, so that you can fix up any missed exceptions that crash your app.

There’s lots more to learn about iOS exceptions and errors in the iOS documentation.

Share this post

Debugging errors in Raygun4Net

So you’ve integrated Raygun into your .Net project, followed the instructions to a T, and you’re still not seeing any errors on your dashboard. Or maybe your app used to report errors, but has stopped and you don’t know why. Don’t worry, I’m here to walk you through my debugging process so you can get back to zapping errors and cutting code like a pro. Lets start with the most common case:

You’ve added Raygun4Net and it’s not working.

The very first thing you should do is make sure you’ve got your API Key right. Copy-paste errors happen, it’s nothing to be ashamed about. Open your web.config or app.config (depending on whether you’re working on a website or app project, I’m just going to refer to it as your configuration file from now on), find your <RaygunSettings> element and check the apikey attribute and make sure it is set to the the right data (check your Application’s Settings for your API Key).

If this is set up correctly, you should be able to create a new Mindscape.Raygun4Net.RaygunClient, and it should have it’s API Key set automatically. You can test it with the following code:

This should create a new Error in your Raygun Application. If it doesn’t, we need to go deeper. In your configuration file, add the throwOnError="true" attribute to your <RaygunSettings> element. This will cause Raygun4Net to throw an Exception if it can’t report your Exceptions (how very meta). You then execute the Test code from above again with a debugger attached, and see if it throws an Exception while trying to send. This will let you know if there is some problem contacting Raygun, and give us something to work with if you contact support.

One error that I have come across a few times is incorrect <configSections> declarations in the configuration file. ConfigSections have a strict format – the

entry MUST be directly inside the <configSections> element. It can’t be nested inside a <sectionGroup>. Your app/website will probably fail to load if you get this wrong.

Raygun used to work, but doesn’t any more

First things first – run through the diagnostic steps above, as if it never worked. Someone could have changed the code while you weren’t looking, or changed the firewall rules and blocked, or something else. At a minimum, run the test exception code to triple check that you can send test errors.

Another way things can go wrong is your trial account expiring. Once your trial has expired we stop processing errors – easy fix, sign up for one of our tasty plans. You can tell it’s in this state if you go to your Application Dashboard and it gives you “Your trial has expired” instead of your errors.

Another thing that can happen if you account is left expired for too long is your API Keys are rotated – it’s worth checking them if you’ve re-activated your account.

Finally, if you’ve picked “Reject all new errors until the start of my next billing cycle” on your plan or are an Azure or Heroku customer you might have exhausted your allocation of errors for the month. Check your Plan settings page, there’s a panel on the right that shows you how far through your Storage Limit you are this month. If it’s at 100% and we aren’t able to auto-upgrade you to the next plan (if you’ve chosen to disallow that, or are billed through Azure or Heroku) then we’ll stop accepting new errors for your account.

If none of this helps, then you need to talk to a human. Either email us at or click the Feedback link inside Raygun. The Feedback link is probably better as we can see your account details quicker that way, but either is fine. One of our lovely support people will be in touch as soon as they can.

Share this post