The core Sentry product: error tracking

The world of software bugs is vast, and while there’s no established delineation between these pesky terms, we can assume the following for future reference:

Software Error: Any event or condition during the execution of a program that disrupts the normal flow of the code.

There are many classes of issues that may arise during development and execution (i.e. the actual running) of a software application, each with their own quirks and methods for handling.

Sentry is a platform for monitoring and tracking these errors in software applications. By default, it handles and reports any uncaught errors (those not encapsulated in a try/catch block), while also allowing collecting the handled errors. Capturing the errors is just the first step: Sentry also does most of the dirty work in classifying, grouping, and visualizing errors to make them legible and easy to take action on.

What Does Sentry do?

Software Errors: 101

Bugs, errors, crashes, exceptions, defects, etc. WTF?

The world of software bugs is vast, and while there’s no established delineation between these pesky terms, we can assume the following for future reference:

Software Error: Any event or condition during the execution of a program that disrupts the normal flow of the code.

There are many classes of issues that may arise during development and execution (i.e. the actual running) of a software application, each with their own quirks and methods for handling. Some examples include:

• Syntax Errors: Writing code is similar to prose - there are rules of properly structured language. Syntax errors occur when the application contains mistakes or typos, like missing semicolons or misspellings of variable names. And unlike prose, these kinds of small errors can actually break the entire thing.
• Language-specific errors: Programming languages and frameworks are built off distinct APIs and objects, meaning there are errors that are specific to the nuances of a specific language.
• /HTTP Errors: HTTP is the protocol for how internet resources talk to each other (and how you’re accessing this article right now). There are error codes associated with all HTTP request issues, and mistakes are common.
• Performance Issues: Long-standing resource requests, slow times to page load, network bottlenecks, and other scary villains can make your app load slow, or worse, not load at all.

What happens when these errors pop up? Well it depends.

Syntax errors, for example, are likely to be caught before code gets “seen” (read: run) by the user; that is, during the initial compilation (translating the code to a computer-readable format). When the code doesn’t compile, the server will throw an error before the application makes it to an end user. In other words, there are lots of safeguards in place to make sure these kinds of errors don’t bring down the whole application.

Certain language-specific errors may occur at run-time (while being run by a user). These errors may contain code that compiles correctly but behaves unexpectedly. An example? Imagine a web-app built in Javascript that asks for a user’s name, though doesn’t account for a user erroneously entering a number instead of letters. If the developer wrote some code to capitalize the first letter using Javascript String methods, the application would crash under other input types (like a number).

An HTTP error may result in a few outcomes - if the application tries to connect to an API and can’t find the source (and receives a 404 error - resource not found), the app may crash if there is no explicit handling of this scenario.

So, how does one minimize app crashes and bugs altogether?

Error Handling

Developers are aware that errors can occur, and most languages provide some simple constructs to address potential issues. The most common is the try-catch block, which allows the application to try to execute some code, and if it doesn’t work, catch it in another code block to handle it gracefully in some specific way.

In this example, the code prompts the user for their full name. It then tries to run some logic, first checking its data type (to ensure it’s not a number, or something else). If there are no errors identified, it displays the full name, capitalizing it using the String toUpperCase method. If there are errors, it throws an error to be cau_ght in_ the catch block, allowing the developer to handle the issue as they’d like.

Companies are dependent on providing reliable services to their users. As these applications grow, code sprawl becomes natural and quality begins to falter - it becomes more and more difficult to enforce error handling and robust tests across all potential edge cases. With the cost of downtime growing, and the time spent identifying root causes of issues consistently high, it created a space for a more encompassing solution.

Enter Sentry.