Common Android exceptions and how to debug them with Raygun

1-android-errors

Java and Android offer a rich and powerful set of tools for creating compelling mobile apps. The development of those apps can be quite productive these days, with modern tools like Android Studio, Gradle and Git. When it comes to releasing your app onto Google Play Store, however, the software development lifecycle dictates the job is only beginning. The maintenance phase is the most critical, and has the highest associated costs for fixing bugs that aren’t identified earlier during implementation or testing.

Fortunately, error tracking tools like Raygun can help catch runtime errors that slip through the QA process, and alert you when your app crashes for your users. Often, they’ll be quick to delete it from their devices, but you can save a customer and potentially negative reviews by informing them when it’s fixed, without them having to lift a finger. It doesn’t take much to amaze users with great support, who will then recommend your app to their friends and family without hesitation. Much better than a bad review for a buggy app!

There are many common Android exceptions that Raygun and its open-source provider Raygun4Android can alert you to when they occur on your user’s devices, and what follows is a list of the most critical.

OutOfMemoryError

This error can happen at runtime when you ask Dalvik to allocate a large amount of memory on the heap – for instance when trying to add a large bitmap into a container like an ImageView. If you’re pulling the bitmap from a remote endpoint you need to be sure you’re guarding against files, as these might cause the app to crash if this exception isn’t handled. There are configuration flags available such as android:largeHeap in the AndroidManifest if you do need to allocated large objects.

Application Not Responding

This very common dialog is caused by the system killing unresponsive applications that have hung on a long-running operation. This could occur when a network I/O connection to a third-party is unresponsive, perhaps due to unreliable connectivity, and many other such conditions. It is critical you keep the UI thread buttery smooth by offloading all long-running tasks onto an appropriate function, such as AsyncTask, or the classic Thread class if you need more control.

NullPointerException

If I had a dollar for every one of these I’ve seen..

It’s pretty easy to advise null guards around every variable access, but there’s always one degenerate case that slips though. As above, if these aren’t handled correctly higher up, the app will crash. Raygun4Android will catch these at the highest level possible, making sure you know where the holes in your app are, so you can fix them without your users needing to file a potentially unhelpful bug report.

StackOverflowError

You might run into this one which indicates infinite or deep recursion when creating nested layouts programatically. Ideally these will be caught during implementation, but in the case one slips through to the public release, Raygun will catch these.

Other common Java exceptions

You’ll also come across the standard set of built-in Java exceptions, depending on your problem domain, how your app is constructed and what libraries you are using – including InterruptedException, IOException, various subclasses of RuntimeException, ArithmeticException, and a whole bunch more. The good thing is, you don’t just need to rely on the compiler and the testing phase to ensure an app that is fit for purpose. Raygun exists as a constant monitor of code in the wild, that allows you to fix exceptions as they occur (and they always do).

Do you already have a Raygun account, are using it with a server-side language and would like to integrate it with your client Android apps? You can get started by creating a new application in Raygun and following the instructions. If you don’t yet have an account, you can start your 30-day free trial here (no credit card needed).

If you have any questions about how Raygun can help track errors in production Android apps, let us know in the comments below. Good luck with the error blasting!

Share this post

Speed Up Your Error Blasting With Our New and Improved Error Details Page

Whilst we’ve been constantly improving the core functionality of Raygun and our first class support for all our language providers, we’ve also been hard at work improving the presentation of data that Raygun collects. It’s always been our focus to let developers solve errors and user issues faster, and today we are pleased to show you the first in a long line of updates to the Raygun UI.

The error group page is one of the highest frequency pages in the entire Raygun application, it’s where you dig into the diagnosis of each error, so it’s a great place to start! Here’s an overview of what’s been updated and why it’ll help your team blast away software bugs at record speed!

Error instance table

The error instance table in many ways is the critical part of Raygun. This redesign is essentially a port of the current one, but features many UX enhancements and a few handy new features. Information density is much higher, stack traces are now colored to help you pick out key data at a glance, local variables are supported (currently for Python, more to come), and request, environment and custom data is now pretty printed and more readable.

Essentially our goal was to get as much data above the fold as possible and into your hands with minimal scrolling – we think it’s a huge improvement and we hope you do too. The favourite stars also remain on the right hand side, clicking these ensures the data you really want to see is accessible on the Summary tab, rather than having to click to the other tabs each time.

Error instance table

Integrations

The integration control functions as before with all the current integrations, but with an improved modal UI. From here, like in the example you can create new issues in your project management tools, or link errors with existing issues. For team chat providers like Slack or HipChat, setup is amazingly straightforward, and error notifications will be lighting up your team chat rooms like it’s Christmas time.

integrations

We have lots of awesome integrations including team chat, project management apps and issue trackers to choose from, plus more on the way. If you haven’t set up an integration yet but use any of these tools below, you can set them directly from the new error details page or from the link under Application Settings in the sidebar.

Screen Shot 2015-06-25 at 3.52.22 pm

Comments

The events/comments control is now always expanded, as we had feedback that indicated this data wasn’t as discoverable as we wanted. It’s out of the way at the bottom of the page, but you can scroll to it by clicking the ‘Events’ button in the header. This list includes Raygun user comments and status changes over time – most recent first. Comments are a great way to keep your team informed of the status of an error group, whether it’s been looked at, worked upon, asking questions or has a previous history, it’s all there for you to share this information with your fellow team members.

Comments

Occurrence history and affected users

Data at the per-error group level has been moved to a sidebar which contains more formatted DateTime data and a new chart that gives you an overview of the frequency of error instances over the life of the group. The sidebar also has a control that shows the affected users (if set up) and the browsers which the error instances originated from (if it’s from a web context). All of this has been designed to give you the data you need, at a glance.

sidebar

Let us know your feedback

We hope that you find these updates improve your workflow and we welcome your feedback on these updates. Just hit the feedback link in the Raygun application and get in touch.

Like what you see but don’t have a Raygun account yet? What are you waiting for? We’ve got a FREE 30 day trial so get started today!

Share this post

3 tools I love for building Node.js apps

Every developer has a set of tools that they use when building software, no matter what language or frameworks they use. Choosing tools can be tricky though, especially when you’re getting started with a new development platform. When I started writing code I went fully down the Microsoft route – Visual Studio, Windows, .NET (Well actually VB6 and ASP Classic, but we’ll gloss over that).

Then I read about Node.js and decided that I had to learn it. I spent a few hours getting setup and finding some useful tools, which quickly evolved when I got my head deep into the Node world.

Webstorm

webstorm

Like most others I know, I started writing Node code in Sublime. The “lightness” of the editor after Visual Studio was refreshing and some of the smart editing helpers are kick arse. As my project grew it became harder to keep everything in my head and I was missing autocomplete.

After trying a few heavier editors, I settled on Webstorm as it’s still quick and provides decent autocomplete and a large number of sweet refactoring tools to make writing code even quicker. And coming from Resharper in Visual Studio, it was nice having similar keyboard shortcuts and tools available.

node-inspector

I initially struggled with debugging in Node. In Visual Studio you mark a breakpoint and press go. Node, being Javascript, is a little different. I started using console.log everywhere, but as you can probably guess, that became unreadable pretty quickly. And still didn’t help me pinpoint exactly where the issues were coming from.

node-inspector comes to the rescue here! Being based off the Chrome Dev tools, we already know how good the Javascript debugging tools are. Being able to step through your code and view local variables is immensely useful when figuring out why something is coming back as undefined or null. Being able to pause your code also lets you dig deeply into object trees which is far easier than dumping them out to your console and trying to scroll back through them.

Grunt

I use Grunt to run a large number of automated tasks against my code base, but one of the most useful and timesaving tasks is ‘grunt-nodemon’. Nodemon watches your code directories and restarts your Node process each time something changes, saving you having to find your terminal window, exiting Node and kicking the process off again. Whilst it may only take a few seconds, it all adds up over a day of development. And anything that saves you keypresses is a good thing, right?

How about you?

What tools do you find super useful when building Node apps? Let me know in the comments! Want to track errors in your Node.js apps? Try Raygun for free today!

Share this post

Webinar: Improving Your App Quality

If you’d like to view the presentation, here are the slides from the Raygun webinar series:

Three completed sample projects demonstrated for setting up Raygun are here for JavaScript, WPF and Xamarin Forms using Dependency Injection.

Some useful plugins for Xamarin (Device, Settings, etc..): https://github.com/jamesmontemagno/xamarin.plugins

Affected user tracking: https://github.com/MindscapeHQ/raygun4net#affected-user-tracking

Tags: https://github.com/MindscapeHQ/raygun4net#tags-and-custom-data

.NET Platforms: https://raygun.io/docs/languages/net

Language support: https://raygun.io/docs/languages

Plugins: https://raygun.io/docs/plugins/

Workflow: https://raygun.io/docs/workflow/

Raygun blog: https://raygun.io/blog/

Case Studies: https://raygun.io/blog/case-studies/

Dependency Injection: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/dependency-service/

Follow us: @Raygunio

Share this post

Tools I couldn’t market tech without

I’ve written numerous times about what a tough crowd you developers are to market tech products to. You’re smart, witty, cynical people who can smell an insincere salesperson a mile away.

But over the years, I’ve discovered a bit about what works and what doesn’t – and the truth is that I couldn’t do my job without the help of some of the marketing tools available to me.

I know that a bunch of our Raygun customers are developers-turned-entrepreneurs, and marketing tech is a problem faced by many – so I would like to kindly share my wisdom with you so that you may also crush it with your tech marketing skills.

So without further ado, here’s a run down of the tools I use to:

Make marketing tech just a little bit easier!

Buffer

Our team creates A LOT of content on our blog and website, some of it about Raygun news and most of it tech tips and tricks that we want to share with our users. When it comes to sharing that content with the world, in different timezones – I couldn’t do it without Buffer. I’m based in our New Zealand office, which is all the way down the bottom of the earth (think hobbits and rugby) and if I had to send every Tweet, Facebook update, Google+ post and Linkedin message in real time, it would mean I didn’t do any sleeping, and I am just not a nice person when that happens.

Automated swag services

People. Love. Swag. Do not underestimate how valuable swag is for delighting your customers. The things people have said to me because they wanted a Raygun sticker would shock you (or not, I’m not sure how far you’ve delved into the depths of the internet). We also do T-shirts (which our customers like so much they go canoeing in them), and little DIY wooden Raygun kits. Services like Printfection and Startupthreads have APIs that you can integrate with which do practically all the work for you. No more sitting in your office until midnight packing t-shirts into boxes – your customers can fill out a web form with their address and T-shirt size which goes directly to the swag service – who choose what is needed from your inventory and send it straight to your fans. (In case you were interested, we get our stickers made at Stickermule, and yes you can have one).

Intercom

I feel like this probably isn’t their official marketing message – but I think of Intercom as my ‘customer happiness tool’. Our entire team use it to communicate with anyone interacting with our product, from new users to users who have been with us from the start. A happy customer is one who doesn’t slip through the cracks when they reach out to you. You just have to be there for them, man.

Moz

When it comes to SEO, MOZ has all the answers. I first learnt what search engine optimisation even was from the MOZ blog, and we’ve used MOZ tools for years to manage anything to do with keyword rankings, links, social, brand, content and traffic (along with Google Analytics). Also, the founder of MOZ, Rand is a super nice guy whose regular Whiteboard Friday videos are some of the best marketing advice you will ever find. As a side note, his wife Geraldine writes a hilarious travel blog that I love and is one of the best things on the internet, in my opinion.

Clicky

If you’re into data driven marketing, you need to be tracking every campaign you do – and Clicky does a great job of that. Like I always say, coffee is for trackers only (actually I usually say coffee is for bloggers only – but I can be flexible with my threats). Clicky helps me find out pretty much everything I want to know about our website visitors; like where they came from, are they organic or paid visitors, how long they stay and what pages they visit.

So these are just a handful of the tools that I love for making my job a whole lot easier. And that’s just for my marketing efforts, the Raygun dev team have a pretty impressive list of tools they rely on to make our service as polished as possible. We even use our own product for error tracking on itself. We often see an error report inside Raygun, that’s been identified by Raygun and sent to Raygun. Pretty trippy right!?

Now while you’re trying to get your head around that, you should sign up for a free 30 day trial of Raygun, and see for yourself how it can improve your workflow and make error tracking a breeze.

Share this post

What to Look For in a Great Error Tracking Service

The sheer amount of DevOps tools on the market these days often leads to confusion for some about which tools they should actually use. Some have more benefits than others, and many developers seem to adopt favourites that they tend to always go back to – The tools they know aid in their software development. Here we’ll look into why a great error tracking service like Raygun is worth its weight in gold!

Creating a workflow around errors

Traditionally speaking, back when error tracking tools were not so advanced, many developers tended to set up email alerts. Basically, when a new error occurred a script would send the un-handled exceptions to the developer’s inbox. That’s fine if you have only a small application that generates minimal errors, but once you start adding on various bits and pieces, notifications become noisy and you start to take a passive interest in the errors that come in. Suddenly you’ve missed an important error, hidden amongst a bunch of errors you really didn’t care about.

error tracking software

Tools these days are smarter and group errors together that are seen as similar. This not only cuts down on notification noise, but also allows better prioritization of error severity. Raygun also has a smart workflow system, allowing you to mark specific error groups as Active, Resolved, Ignored or Permanently Ignored. Your team can also link errors with other tools like Issue Trackers, Team Chat and Project Management tools, it’s all aimed at creating a workflow for software developers to be more productive and fix errors quickly, before they cause you bigger problems.

Full, Usable Stacktraces

Being alerted of an error is one thing, but how do you know where to look for a solution. Gone are the days of having to ask users for screenshots, environment information and trying to replicate the issue. A tool like Raygun can give you all of this information at a glance, including the stack trace. This gives you enough information to find the problem, right down to the line of code the error occurred on! What a time saver!

Not all programming languages generate usable stack traces (I’m looking at you Objective-C. You too minified JavaScript!). That’s when post-processing comes in helpful. A tool like Raygun can automatically take those stack traces and transform them into a structure that make them far more actionable by your development team. Further to this, for some languages like Python, Raygun can even tell you local variable values at the time of a crash! Gone are the times of wondering how an error could even occur.

Works everywhere

Some services focus on a specific language, and they’re very good at tracking errors on that particular technology or framework. An advantage with Raygun is it works across 24+ programming languages and platforms. Want to track errors across your Node.js backend as well as your iOS or Android app? No problem! Each provider allows for custom error grouping logic and features, giving you a full technology stack solution. You can even track all of your applications in one view.

Smart Notifications

Want to be notified of errors in your own time zone? Want to be notified in a daily digest at a specific time of day? Want to have error notifications pop up in your team chat provider like HipChat or Slack? Want to be notified of specific applications in specific ways? It’s all possible, you just need to have a service that supports it all. Raygun offers all this with unlimited team members, and what’s more, all of them can have individual settings for email notifications.

Filters

As we said earlier, getting to the problem as quickly as possible in order to fix it is very important. Filters allow you to search upon specific criteria, whether it be Hostname, version, date, time or many more. Applying filters gives you error groups that match the requirements you need to look into. This ensures that finding errors is no longer a case of finding a needle in a haystack, as you can drill in and find the issue you are looking for in record time.

Needle in a Haystack

If a user has reported an issue and can tell you the time it happened or any other nugget of information, you’ll be able to find the exact error instance in Raygun that affected that user! It’s so easy!

Saving Money

If you don’t think that paying for an error tracking service is worthwhile, step back and look how much time it can save you. Software developers that tend to not want to spend money on a service, often lose out with the time they spend maintaining their own solutions, managing extra servers that they host themselves for error tracking, or generally lose time fixing bugs that a good error reporting service may have identified and pointed them to in a lot faster time period. Remember that every time you are fixing software errors – that time is taking you away from building new features. How much is that costing you?

I hope you found this useful in answering why a good error tracking service is a good investment and how it can aid your software development.

Want to give Raygun a try? There’s a 30 day FREE trial available!

Share this post

Raygun Webcast, Improving Your App Performance

Limited seating. Sign up today and reserve your seat!

https://attendee.gotowebinar.com/register/8707233058375978497

June 18, 2015 5:00 PM – 6:00 PM EDT

IMG_8157 smallJoin MVP and Raygun Community Evangelist Russ Fustino as he talks about Raygun, a great error reporting tool that is fast and reliable, no matter what the load. In this introductory webinar, see how Russ uses Raygun during the development cycle to help debug errors and discover hidden problems from live production data – improving app performance. Raygun is also great for the production environment and gives you real time data and affected user information, across ever major programming language and platform, including JavaScript, .NET, Ruby, iOS, Android and more. Be proactive, find and fix errors before your users experience them. See an overview of Raygun and the many supported platforms and integrations. You’ll be amazed at what Raygun can do and how much it can improve your software development, don’t miss this one!

Start your free trial today! raygun.io  and follow @raygunio

Russ Fustino is a MVP and Raygun Community Evangelist and a highly experienced software evangelist. As well he has developed and published Windows Store, Windows Phone 8.1 Universal, Xamarin iOS, Android and WP 8 apps. He is a former Developer Evangelist for Xamarin, ComponentOne and Microsoft and is CEO of Fustino Brothers, Inc (FBI). FBI Tull apps are endorsed by Jethro Tull. Russ is an INETA Lifetime Achievement Award winner for helping educate, entertain and enlighten over 1 million programmers. Check out Russ’ blog at www.russtoolshed.net/blog  and follow @RussFustino

Share this post

Useful Javascript debugging tips you didn’t know

The Raygun team is made up of a bunch of nerdy folk just like yourself. Occasionally they write about tools they like and thoughts they have about dev-type topics. This week we’ve got Rick, our longboarding-freediving-Swedish speaking front-end dev talking about ‘things you didn’t know about Javascript debugging’.

Knowing your tools can make a major difference when it comes to getting things done. This is a list of small debugging tips you probably didn’t know but soon won’t live without. In this post, most of the tips are for Chrome inspector even though my favourite tips are for Firefox. Many of these tips will work in other inspectors as well.

Quick find your DOM elements.

Mark a dom element in the elements panel and use it in your console. Chrome inspector keeps the last 5 elements in its history, so the last marked element will be displayed with $0, second to last marked element $1 and so on.

If you mark following items in order’item-4′, ‘item-3′, ‘item-2′, ‘item-1′, ‘item-0′ then you can access the DOM nodes like this in the console.

Debug javascript

Display object as tables

Sometimes it can be a bit messy to view a lot of data with console.log. You can display a list of objects as a table to view complex sets of data more easily.

Will output…

console.table
console.table

Get the stack trace for a function

If you’re using a javascript framework you know that it quickly produces a lot of code. Views are created, events are triggering functions and in the end you want to know what caused this function call. Since Javascript is not a very structured language it can sometimes be hard to get an overview of what happened and when. Especially when you jump into someone else’s code. This is when console.trace (or just trace in the console) comes handy.

Imagine you want to see the entire stack trace for the function call funcZ in the car instance on line 33:

Line 33 will output…

Console trace
Console trace

Now we can clearly see that function func1 called func2 which called func4. Func4 created an instance of Car and then called the function car.funcX and so on.

Even though you think you know your script well this can still be quite handy. Let’s say you want to improve your code. Get the trace and your great list of all related functions. Every single one is clickable and you can now go back and fourth between these functions. It’s like a menu of functions just for you.

Quick find a function to debug

Let’s say you want to set a breakpoint in a function. The two most common ways to do that is probably to find the line in your inspector and add a breakpoint. Another way would be to add a debugger in your script. In both of these solutions, you have to click around in your files to find the particular line you want to debug.

What is probably less common is to use the console. Use debug(funcName) in the console and the script will stop when it reaches the function you passed in. It’s quick but the downside is it doesn’t work on private or anonymous functions. But if that’s not the case it’s probably the fastest way to find a function to debug. Note that there’s a function called console.debug which is not the same thing.

Type debug(car.funcY) in the console and the script will stop in debug mode when it gets a function call to car.funcY.

debug(car.funcY)
debug(car.funcY)

Black box scripts that are NOT relevant

Today we often have a few libraries and frameworks on our web apps. Most of them are well tested and relatively bug free. But we still debug our own scripts and the debugger still steps in to all those files that have no relevance for this debugging task. The solution is to black box the script you don’t need to debug. This could also include your own scripts. Read more about black boxing in my previous article javascript-debugging-with-black-box.

Find the important things in complex debugging

In more complex debugging we sometimes want to output many lines. One thing you can do to keep a better structure of your outputs is to use more console functions like: Console.log, console.debug, console.warn, console.info, console.error and so on. You can then filter them in your inspector. But sometimes this is not really what you want. It’s now that YOU can get creative and style your messages. Use CSS and make your own structured console messages.

will output…

Custom console message
Custom console message

In the console.log() you can for example set %s for a string, %i for integers and %c for custom style. You can probably find better ways to use this. If you use a single page framework you maybe want to have one style for view message and another for models, collections, controllers and so on. Maybe also name the shorter like wlog, clog and mlog. It’s time to use your own imagination.

Watch specific function calls and it’s arguments

In the chrome console you can keep an eye on specific functions. Every time the function is called it will be logged with the values that was passed in.

Monitor
Monitor

This is a great way to see what arguments are passed into a function. But I must say it would be good if the console could tell how many arguments were expected. In the above example func1 expect 3 arguments but only 2 is passed in. If that’s not handled in the code it could lead to a possible bug.

Quickly access elements in the console

A faster way to do a querySelector in the console is with the dollar sign. $(‘css-selector’) will return the first match of CSS selector. $$(‘css-selector’) will return all of them. If you are using an element more than once it is worth it to save it as a variable.

debug javascript

Post man is great but Firefox is faster

Many developers are using Postman to play around with ajax requests. Postman is great but I must say it’s a bit annoying to open up a new browser window, write new request objects and then test them. Sometimes it’s easier to use your browser.  When you do so you no longer need to worry about authentication cookies if you are sending to a password secure page. This is how you would edit and resend requests in firefox.

Open up the inspector and go to the network tab. Right click on the desired request and choose Edit and Resend. Now you can change anything you want. Change the header and edit your parameters and the simply hit resend.

Below I resent a request twice with different properties.

Edit ajax request

Edit ajax request

Having said that postman is still great and has other benefits.

Summary

This article may not change the world but I hope those small tips and tricks will make your coding day easier and more fun. If you like to speed up your workflow I can also recommend you to read:

Want to make Javascript debugging even easier with your own apps? Raygun has a free trial available and works with Javascript. Get started today and start blasting away software errors in record time!

Share this post

Fix ‘Script Error’ and get the most data possible from cross-domain JS errors

If you’re working on a website and have Raygun hooked into its client-side JavaScript, one of the first things you probably noticed was the rather unhelpful “Script Error” appearing in your dashboard. You may have also seen this appear in the browser console while developing, and noticed that Script Errors are thrown when errors from scripts loaded from a different domain than the origin are caught by the global window.onerror handler.

Browsers may behave in this way as a security feature to protect against potentially malicious scripts injected or hosted by other sites from reading user data such as cookies (quite rightly, I’m sure you’ll agree). This is termed the Same-Origin Policy, and means that scripts only have full access rights if they are loaded from the same origin domain as the original document (when the script passes the CORS validation).

The Same-Origin Policy

CORS and the Same-Origin Policy do however present a problem with regards to the architecture of modern web sites and applications. Due to the nature of HTTP 1.1, frequently key resources including JavaScripts are hosted on non-origin (also called ‘third-party’) domains – in particular CDNs, as using the massive resources of public clouds keeps both costs and response times low. The main problem is that if your web application code is defined and loaded in a script hosted on a different domain to the one in the address bar, errors that hit window.onerror won’t have any stack trace or message context for you to debug. This is not a problem when developing locally, but becomes a critical issue when trying to figure out why a site is breaking on a user’s machine. This is most obvious when Raygun4JS reports these errors, and the error groups lack any indication as to what happened.

The spec and implementation for controlling the Same-Origin Policy is documented nicely here. In particular the Browser Compatibility matrix is a valuable read; you’ll notice proper implementations are only available in recent versions of the evergreen browsers, come with caveats in the bug tickets, or are plain not supported.

There are two key pieces of metadata needed to allow a cross-domain script to report errors correctly in a modern browser. As the documentation lists above, the first is the presence of the ‘crossorigin’ attribute on the appropriate script tag. By example:

The second critical bit of data is the presence of an HTTP header on the response from the third-party domain containing the JavaScript. This is:

The wildcard in this example allows all sites to report errors with full data, and is appropriate for a CDN where the script may be requested by any third-party domain. If this is a private host for a known set of domains, you can provide that list in place of the wildcard.

Different browser behavior

Depending on what browser your users are running, the above properties may or may not have an effect. This sums up the situation as of writing:

  • Chrome 30+
  • Firefox 13+
  • Opera 12.50+
  • Safari (at least 6+)

In these browsers, if the script attribute is present, the HTTP header will need to be also present, otherwise the script will be blocked.

Firefox has additional behavior for RuntimeErrors. These will be provided to window.onerror regardless of the two properties, as apparantly these aren’t considered a security risk. Syntax errors, however, will be blocked in both Gecko and WebKit browsers, if crossorigin is present but the associated cross-origin domain lacks the header.

  • Internet Explorer <= 10

Errors will be reported with all available data in IE 10 and below – now considered a security issue.

  • Internet Explorer 11+

Third-party errors will not contain any data, and the attributes are not respected at current time – we’re hoping that Microsoft Edge will resolve this.

Ready to blast errors

Like many elements of software dev, there are pitfalls to be aware of when it comes to security and legacy platform support. CORS support and third-party errors are just one of these, but hopefully with the above guide you should be able to ensure you are receiving the error data you need to fix bugs on your cross-origin scripts, while guarding against malicious third-party scripts and script injection.

Got questions about this post? Let us know in the comments section below. If you haven’t tried out Raygun, see what the buzz is about by starting your free 30-day trial here, no credit card needed.

Share this post

JavaScript debugging made easy with Source Maps

Source maps are a useful tool for debugging and fixing minified JavaScript code without the hassle of determining where in the original code an error occurred. They provide a way to translate between minified code, designed to decrease webpage load times to the source code the developer writes.

This post gives an overview of setting up and using source mapping in your browser as well as within Raygun.

If you’re unfamiliar with source maps it’s probably best to see how they work within the browser. You can read about how to generate source maps here.

Source Maps are natively supported by both Google Chrome and Firefox as well as IE11, this means that any minified JavaScript files with a source map comment at the bottom will automatically link to its sources so long as the mapping and source files are in the correct locations.

This allows errors to be mapped onto the original source code instead of reporting errors on only the minified script.

For instance if a minified file example.min.js has the following comment at the end of the file

the browser will load the mapping file example.js.map in the same directory as the minified file. Any source files specified by mapping file will then be loaded into the Sources window in the browser console.

In addition to showing the source files in the sources window, any errors which happen within the minified file will automatically be mapped into the source files allowing for easy debugging.

Now that you have an idea about how source maps can be used to review code and debug locally, here is an overview of how source maps can be used with Raygun to debug script errors reported from client’s browsers.

When an error occurs in the JavaScript of a website using Raygun an error report including stacktrace is send to Raygun.

Contained within the stacktrace are the URLs of the scripts in which the error occurred.

Given these URLs Raygun can download each script file and check for a source map comment. If the comment exists it tries to map the line of the stacktrace onto source code. This is done by downloading the map file specified.
If a map file is available Raygun can then perform the mapping which converts the lines numbers of the stacktrace on the minified code into line numbers on the source files, it also resolves the source files. Given the source file URL we make additional requests for the source files. If we can retrieve these we insert a snippet of the source code into the stacktrace to give context to the error.

All of this can be done across the public internet if the files are hosted at the correct URLs and are publicly available.

For many people hosting JavaScript files publicly is not in their best interests. For this reason Raygun provides a source map center, this is a private store of JavaScript files to be used in the source mapping process. It allows source mapping to work without hosting anything publicly.

If a file is uploaded into the source map center it will be used instead of requesting a file from the internet. All that is required is that the file be labeled with the URL it would be accessed from if it were to be publicly hosted. In most cases this is easy to figure out. For minified files it’s simply the address your minified files are served from. The address of the map and source files may be a bit harder but can usually be figured out by looking at the relative URLs in the generated sourceMappingURL comment in the minified files as well as the sources section of the map files and figuring out the absolute URL based on the address of the minified files.

Hopefully this post has given an overview of how Raygun can be used to produce powerful error reporting for minified JavaScript code in production environments.

Want to see this in action with your own apps? Raygun has a free trial available. Get started today and start blasting away software errors in record time!

Read the full documentation about how to set up Source Mapping in Raygun in the docs.

Read here about enabling source map debugging in Google Chrome  and Firefox.

Share this post