JavaScript Error Handling

JavaScript Error Handling – RangeError: argument is not a valid code point

Plowing straight ahead through our JavaScript Error Handling series, today we’ll be exploring the fun world of the Invalid Code Point error.

Below we’ll examine what causes an Invalid Code Point error, followed by how to capture and handle this error. Off we go!

The Technical Rundown

  • All JavaScript error objects are descendants of the Error object, or an inherited object therein.
  • The RangeError object is inherited from the Error object.
  • The Invalid Code Point error is a specific type of RangeError object.

When Should You Use It?

Generally speaking, the core RangeError object manifests anytime a designated value does not fall within the range or set of allowed values. The type of value and circumstance this can appear in varies, hence why RangeError has a number of unique objects under its umbrella, intended to report on whichever error is most appropriate.

For this post, we’re examining the Invalid Code Point error, so first we must discuss what a code point actually is. Typically, a code point refers to the number and position of characters within a character encoding scheme, such as ASCII or Unicode. In the case of JavaScript and the Invalid Code Point error, the code point always refers to an integer value that represents the Unicode character scheme, within the range of 1,114,112 characters that Unicode is comprised of.

One method of utilizing code points in JavaScript is through the String.fromCodePoint() method, which returns a Unicodestring from the specified sequence of code point parameters.

For example, we can output the Black Chess Queen character, which is Unicode number U+265B, with the following code:

Which outputs a nice little Queen character: ♛

While we accessed this character above using hexadecimal, we can also do so via the numeric integer value instead, which in this case is 9819:

Now, to actually produce an Invalid Code Point error, we simply provide an invalid code point value to the String.fromCodePoint() method. For example, we’ll try giving it a negative number:

We’ve thrown in a basic printError() function to format and output our error message, but sure enough, we see that trying to return the code point Unicode character of the number -10 fails and gives us an Invalid Code Point error:

With a basic understanding of what causes Invalid Code Point errors to occur, it’s also worth considering that our above example of simply grabbing the first instanceof a RangeError object won’t always be our Invalid Code Point error. The RangeError object represents some half-dozen different errors which inherit from the RangeError type. In order to verify that we’re only responding to the specific Invalid Code Point error, we need to add additional logic by parsing the .messageproperty of the error object:

We’ve now thrown in a simple check within the error .message property to ensure it contains the phrase ‘code point’ somewhere in the message text. If so, that is our expected Invalid Code Point error. This means that when a differentRangeError is produced, such as Invalid Array Length, we don’t need to worry.

To help you along the way in your journey towards JavaScript error handling perfection, be sure to check out Airbrake’s JavaScript Error Handling Software!

waterfall model

Waterfall Model: What Is It and When Should You Use It?

First introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall model is a software development process. The waterfall model emphasizes that a logical progression of steps be taken throughout the software development life cycle (SDLC), much like the cascading steps down an incremental waterfall. While the popularity of the waterfall model has waned over recent years in favor of more agile methodologies, the logical nature of the sequential process used in the waterfall method cannot be denied, and it remains a common design process in the industry.

Throughout this article we’ll examine what specific stages make up the core of the waterfall model, when and where it is best implemented, and scenarios where it might be avoided in favor of other design philosophies.

The Six Stages of Falling Water

waterfall model

Actually implementing a waterfall model within a new software project is a rather straightforward process, thanks in large part due to the step-by-step nature of the method itself. There are minor differences in the numbers and descriptions of the steps involved in a waterfall method, depending on the developer you ask (and even the year during which you ask him or her). Regardless, the concepts are all the same and encompass the broad scope of what it takes to start with an idea and develop a full-scale, live application.

  • Requirements: During this initial phase, the potential requirements of the application are methodically analyzed and written down in a specification document that serves as the basis for all future development. The result is typically a requirements document that defines what the application should do, but not how it should do it.
  • Analysis: During this second stage, the system is analyzed in order to properly generate the models and business logic that will be used in the application.
  • Design: This stage largely covers technical design requirements, such as programming language, data layers, services, etc. A design specification will typically be created that outlines how exactly the business logic covered in analysis will be technically implemented.
  • Coding: The actual source code is finally written in this fourth stage, implementing all models, business logic, and service integrations that were specified in the prior stages.
  • Testing: During this stage, QA, beta testers, and all other testers systematically discover and report issues within the application that need to be resolved. It is not uncommon for this phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to be properly squashed.
  • Operations: Finally, the application is ready for deployment to a live environment. The operations stage entails not just the deployment of the application, but also subsequent support and maintenance that may be required to keep it functional and up-to-date.

The Advantages of the Waterfall Model

While the waterfall model has seen a slow phasing out in recent years in favor of more agile methods, it can still provide a number of benefits, particularly for larger projects and organizations that require the stringent stages and deadlines available within these cool, cascading waters.

  • Adapts to Shifting Teams: While not necessarily specific to the waterfall model only, using a waterfall method does allow the project as a whole to maintain a more detailed, robust scope and design structure due to all the upfront planning and documentation stages. This is particularly well suited to large teams that may see members come and go throughout the life cycle of the project, allowing the burden of design to be placed on the core documentation and less on any individual team member.
  • Forces Structured Organization: While some may argue this is a burden rather than a benefit, the fact remains that the waterfall model forces the project, and even the organization building said project, to be extraordinarily disciplined in its design and structure. Most sizable projects will, by necessity, include detailed procedures to manage every aspect of the project, from design and development to testing and implementation.
  • Allows for Early Design Changes: While it can be difficult to make design changes later in the process, the waterfall approach lends itself well to alterations early in the life cycle. This is great when fleshing out the specification documents in the first couple stages with the development team and clients, as alterations can be made immediately and with minimal effort, since no coding or implementation has actually taken place up to that point.
  • Suited for Milestone-Focused Development: Due to the inherent linear structure of a waterfall project, such applications are always well-suited for organizations or teams that work well under a milestone- and date-focused paradigm. With clear, concrete, and well understood stages that everyone on the team can understand and prepare for, it is relatively simple to develop a time line for the entire process and assign particular markers and milestones for each stage and even completion. This isn’t to suggest software development isn’t often rife with delays (since it is), but waterfall is befitting the kind of project that needs deadlines.

The Disadvantages of the Waterfall Model

While some things in software development never really change, many others often fall by the wayside. While Dr. Royce’s initial proposal of what is now known as the waterfall model was groundbreaking when first published back in 1970, over four decades later, a number of cracks are showing in the armor of this once heralded model.

  • Nonadaptive Design Constraints: While arguably a whole book could be written on this topic alone, the most damning aspect of the waterfall model is its inherent lack of adaptability across all stages of the development life cycle. When a test in stage five reveals a fundamental flaw in the design of the system, it not only requires a dramatic leap backward in stages of the process, but in some cases, can be often lead to a devastating realization regarding the legitimacy of the entire system. While most experienced teams and developers would (rightfully) argue that such revelations shouldn’t occur if the system was properly designed in the first place, not every possibility can be accounted for, especially when stages are so often delayed until the end of the process.
  • Ignores Mid-Process User/Client Feedback: Due to the strict step-by-step process that the waterfall model enforces, another particularly difficult issue to get around is that user or client feedback that is provided late into the development cycle can often be too little, too late. While project managers can obviously enforce a process to step back to a previous stage due to an unforeseen requirement or change coming from a client, it will be both costly and time-consuming, for both the development team and the client.
  • Delayed Testing Period: While most of the more modern SDLC models attempt to integrate testing as a fundamental and always-present process throughout development, the waterfall model largely shies away from testing until quite late into the life cycle. This not only means that most bugs or even design issues won’t be discovered until very late into the process, but it also encourages lackadaisical coding practices since testing is only an afterthought.
Ruby Exception Handling

Ruby Exception Handling: ScriptError

Today we continue the Ruby Exception Handling series by taking a look at the ScriptError exception class. ScriptError is actually a superclass, which means it is inherited by other exception classes, and thus when a ScriptError occurs, Ruby determines which of the subclasses is most relevant and raises that error for further examination.

Below we’ll see what can cause various types of ScriptErrors and how to configure your application to avoid them wherever possible, so let’s get started!

The Technical Rundown

  • All Ruby exceptions are descendants of the Exception class, or a subclass therein.
  • ScriptError is a direct descendant of the Exception class.
  • ScriptError is a superclass to the subclasses LoadError, NotImplementedError, and SyntaxError.

When Should You Use It?

Unlike its subclass descendants, ScriptError itself is a direct descendant of the Exception class. ScriptErroritself will never be directly returned or rescued when executing code, but instead Ruby will generate one of the ScriptError subclasses that was raised by the error in question.

This is because ScriptError itself doesn’t directly represent anything; it’s best thought of as a template by which all script-related errors are generated from.

As an example, we can raise a LoadError, which is a subclass of ScriptError, with the following code:

We are covering our bases here and rescuing the explicit ScriptError exception class, but also any generic or unexpected Exception that may occur in the second rescue clause below that.

The output of the above execution where we try to require a file path that doesn’t exist is the raising of a LoadError:

Notice that this exception wasn’t INEXPLICIT, and instead was rescued by explicitly calling the ScriptErrorsuperclass. However, the actual exception class itself that was raised (as represented by the e variable) was not ScriptError, but was instead a subclass of ScriptError, the LoadError exception. As discussed earlier, this is because ScriptError is a descendant of Exception, while LoadError (and others) then descend from ScriptError, as can be seen throughout the Ruby source code.

To illustrate that explicitly rescuing ScriptError works for other exception types, we can also attempt to raise a SyntaxError by evaluating syntactically invalid code:

Once again, our explicit rescue of ScriptError produces a subclass, in this case a SyntaxError:

Since ScriptError is a descendant of Exception, if we completely remove the explicit call to ScriptError in the above example, and only leave the rescue for the generic Exception class, we still get the (INEXPLICIT) result, in this case again the SyntaxError exception:


One particular caveat here, however, is that since ScriptError and its subclasses are not descendants of StandardError, which is the default exception type Ruby creates for rescue clauses without explicit class specification, we cannot use a non-explicit rescue clause and expect any form of ScriptError to trigger that code.

Here we’re using the previous eval() example again, but we’ve removed all explicit class calls in the rescue to either ScriptError or even Exception. Watch what happens with the output:

Our print_exception function is not even called, and the reason is because the actual exception class that was raised (SyntaxError) is not a descendant of StandardError, so the non-explicit rescue => e clause fails to trigger.

To help you along the way in your journey towards JavaScript error handling perfection, be sure to check out Airbrake’s Ruby Error Handling Software!

JavaScript Error Handling

JavaScript Error Handling – Error: Permission Denied To Access Property “x”

As we continue through our in-depth JavaScript Error Handling series, we’ll take a closer look at one of the most basic errors in JavaScript, the Permission Denied error.

Below we’ll examine what exactly causes a Permission Denied error in JavaScript, and how to both handle and avoid this error in your own projects, so let’s get started!

The Technical Rundown

  • All JavaScript error objects are descendants of the Error object, or an inherited object therein.
  • While the Permission Denied error we’re examining here is a base Error object, the Error object itself can be used and extended for custom error constructors.

When Should You Use It?

Since the Permission Denied error does not have an explicit inherited constructor associated with it below the baseline Error object itself, it can be difficult to accurately determine when this particular error has reared its ugly head purely within the standard try-catch syntax of JavaScript.

That said, we’ll begin examining the Permission Denied error with a simple example. This error most commonly appears when JavaScript attempts to access an object for which it has no permission, such as an <iframe> element that is attempting to load content from another domain.

For this simple example, our HTML contains a simple <iframe> with src property that violates the same-origin policy:

Our JavaScript contains a simple printError() function which assists with formatting the output of a passed in error, telling us the error type, the error message, and allowing us to specify if the error was explicitly provided.

Additionally, we have a simple try-catch clause after attempting to access and output the first (and only) frame in our document, the above <iframe>:

The expected output is an EXPLICIT Permission Denied error, and sure enough that’s what we see:

Since we are explicitly checking for our e error object to be an instanceof the Error object, it is expected that this is caught and sent to our printError() function as an EXPLICIT object reference. If we change this so that our catch clause doesn’t check for any explicit instanceof Error, the same error would be produced, but it would be INEXPLICIT by our own measurement:

The real problem with trying to capture the Permission Denied error comes about when we recognize that simply catching an instanceof the base Error object isn’t enough, as this will catch all sorts of other errors that are unrelated.

For example, let’s change our code a little bit to execute a recursion loop and trigger an InternalError: Too much recursion:

Upon execution of our new code where we call the repeat() function, which recursively calls itself ad infinitum, we get the following output:

JavaScript has assumed that our explicit check for our error to be an instanceof Error is what we wanted, even though the actual error object that was caught was InternalError.

As you might imagine, the problem here is that InternalError (along with virtually all other error objects), is a descendant of the Error object, so capturing Error captures everything.

Therefore, in order to properly capture only the Permission Denied error, we need additional logic within our catchclause. Since using the name property for our error does us no good, the only other standard property to the Errorprototype that’s available is message, so we’ll need to parse that to verify we’re getting the Permission Denied error and not something else:

While this is perhaps not the most efficient method, above we’re simply checking whether our Error object message property text contains the phrase permission denied at the beginning, and if so, we can consider that the EXPLICIT error we’re looking for.

The output is as expected:

To help you along the way in your journey towards JavaScript error handling perfection, be sure to check out Airbrake’s JavaScript Error Handling Software!

Java Best Practices

Java Best Practices: 3 Tips For Writing Cleaner Code

Are you looking for one simple way to make Java code easier to maintain, debug, and develop? If so, you should simply adhere to Java best practices in order to produce great code. Great code doesn’t just work well; it is also readable, maintainable, and often, reusable. When you get confronted by a deadline and just needs to get the thing to work, it’s tempting to toss in some hacks. However, these shortcuts are likely to punish you later when you need to debug or upgrade your scripts. If you get into the habit of writing code well, you will save yourself time and money in the end.

Tips to Adhere to Java Best Practices

With this in mind consider these tested Java best practices to produce maintainable code:

1. Keep Java Classes Focused

In a perfect world, each Java class should just represent a specific concept. There’s not a magic number that specifies how many lines of code or how many methods each class should contain, but when classes start growing larger than a couple of hundred lines of code, it’s time to reconsider the program’s design.

Smaller classes will make the code easier to understand. They will also increase the likelihood that the classes can be plugged into other scripts to help with specific tasks. A focus on clean and reusable code will help save money and speed up development for this project and perhaps, future projects.

2. Consider the One-Screen Rule for Java Methods

Ideally, a method should contain one specific function or set of functions. You should be able to see the code for each method on one screen or printed page, so it’s easy to grasp what the function is and how the method gets the job done. As with classes, if your methods start growing much larger than a page, it’s time to evaluate how your script has been designed.

You can write the most complex Java scripts by using short, focused classes and methods. If you have to upgrade or debug your script later, you will thank yourself for following this practice. Also, short and focused methods are much more likely to be reusable.

3. Adhere to a Standard Coding Style

If you adhere to style standards, you should be able to tell where a block of code begins and ends and what that code does. As a simple example, consider this standard style for producing readable code:

Notice that the first brace ends the line of code with the method declaration. The last brace is on a line by itself on the end. Also note that the method gets documented in English with comments. The comments aren’t part of the code; however, they explain what the code is supposed to do. Finally, the name of the method actually describes what the method does.

This might just seem like the standards from Computer Science 101, and that’s actually what they are. At the same time, these standards often get violated by experienced programmers. When code adheres to tested standards, less experienced programmers will be able to maintain it and be able to learn from it. This cuts costs and keeps all levels of developers more productive. It’s fine to develop your own in-house standards that deviate from the basics, but they should actually be documented and enforced standards.

Why Java Coding Standards Matter

Most programmers learn to develop clean and readable code in school. In the real world with its deadlines and much more complex requirements, it’s actually moderately experienced programmers who tend to break the rules in the interest of fixing a bug or meeting a tight deadline. Sadly, some programmers may even write unreadable and complex scripts with the misguided thought that they can make themselves more valuable. It’s obvious that truly valuable programmers write Java that is as easy as possible to debug and maintain.

When you can operate in real-life business situations and still maintain the habit of producing clean code that adheres to set standards, you can pat yourself on the back. You will benefit yourself and your company by saving time, money, and resources.

Ruby Exception Handling

Ruby Exception Handling: NoMemoryError

Next in our Ruby Exception Handling series we’ll be examining the dreaded NoMemoryError exception. As the name implies, a NoMemoryError can occur within Ruby anytime the system attempts to allocate more memory than Ruby can provide or is allowed.

In this post we’ll see examples of what can cause NoMemoryErrors, what it indicates in your code, and how to use or avoid these exceptions in the future!

The Technical Rundown

  • All Ruby exceptions are descendants of the Exception class, or a subclass therein.
  • NoMemoryError is a direct descendant of the Exception class.

When Should You Use It?

To catch a potential NoMemoryError, it’s best to consider the most likely points of execution where the application may utilize too much memory. Typically this occurs when loading a file into memory (such as when downloading or using, or when attempting to allocate more than the allowed memory for a particular Ruby object.

That said, while NoMemoryErrors can be caught using Ruby’s begin-rescue syntax, doing so should typically be a last resort, as Ruby only raises a NoMemoryError when memory allocation fails. It does not typically fire when the application itself exceeds the actual physical memory, and as you might expect, the application will simply crash, the machine will grind to a halt, or any number of other awful possibilities.

As an example of where you might make use of NoMemoryError, it will most commonly occur when dealing with particularly large Ruby objects.

For example, let’s examine some simple code where we’re creating a String object by repeating a single character a specific number of times:

As expected, this would produce a String output that is 10 of the letter “a” in a row:

As you may be aware, most programming languages (and Ruby is no exception) define an unsigned long integer as a number with a maximum of 4 bytes, which means the largest number possible for that long is half of 2 ^ 32 - 1, or 2,147,483,647. This number is halved, because while a signed number indicates both positive and negative values can be represented, an unsigned long can only be positive. Since we have to account for the possibility of zero, the maximum positive value of an unsigned long is actually one less than 2 ^ 32 / 2, or 2,147,483,647.

In Ruby, depending on which version and bit-level you’re using (32-bit vs 64-bit), Ruby does not allow Strings to be allocated in memory that are larger in size than the maximum positive unsigned long size seen above.

Therefore, we can raise a NoMemoryError by using this code:

This produces the following output:

The key line of code here is puts "a" * limit, which tells Ruby that we’re want to output a new String that we’re creating by concatenating the letter a 2,147,483,647 times (which is defined by 2**31 - 1). Ruby responds by producing a NoMemoryError because the allocation size of our new string is too large for what Ruby allows, which we capture using the rescue syntax, in which we output some additional information to make it look like a normal error.

To resolve this NoMemoryError issue, we can make one simple fix: We can shrink the size of our string by one more character, by changing limit to 2**31 - 2:

Depending on where you are executing this code, you may or may not see the interpretor attempt to create and actually output a string that is some two billion characters in length.

Whether or not the actual output works on your system, the key takeaway here is that NoMemoryErrors can be captured within Ruby code when memory allocation gets too overzealous, but the best practice always remains to try to eliminate potential memory leaks before they ever occur.


Technical Debt: How Much (If Any) Is Acceptable?

Technical debt is an ever-present issue in software creation that becomes bigger as a project scales. Although you may not be able to see technical debt, you are paying it all the time if you are not looking for it! Is it ever acceptable, and how should you work to reduce it as much as possible?

Where does technical debt come from?

We should start with what technical debt is not in order to determine where it actually comes from; otherwise, we may mistakenly identify things that are not technical debt as technical debt, eliminating our ability to control it.

Technical debt is not lazy programming, and these two concepts are not synonyms in any way. Huge, unsophisticated modules and overly verbose executables that run inefficiently are problems that can be virtually eliminated by inspiring or changing up your team. In most cases, technical debt comes from a conscious decision and choice that is made by a fully competent team – do we have time to research and test a more efficient solution, or do we have to go with the less efficient but more easily implemented obvious programming choice?

Can we get rid of all technical debt?

Hypothetically, yes. Functionally, no.

If a great group of programmers had an unlimited amount of time to work on a project, they could probably eliminate all of the technical debt in that project. However, there is no company with this unlimited reserve of time. At some point, you are going to have to prioritize the functionality of the code over its artistic merit and even its efficiency.

The secret to technical debt is its management – determining the amount that can be eliminated and properly holding the rest to only an incremental effect on the final product.

Technical Debt and Agile Development

Everyone is looking for more agile development because it is the hottest new term on the market, not because it is necessarily the best process for a project. Agile development creates a more efficient product at the end of the coding, but the process itself is anything but agile.

Agile development is all about breaking down a project into component parts. Each of those parts is then optimized, of course, bringing the entire project to a higher level of efficiency. However, as you employ DSDM, FDD, or XP, you are actually extending your timeline to completion. Some projects simply do not have the time for this intermediate process, not to mention the money that it takes for the extra man hours. When the deadline and the total budget numbers are creeping up, sometimes a project must find its end in a less efficient final effort.

The Amount of Debt that is Acceptable

As with any debt/credit transaction, simply having debt is not a bad thing. Many people have become rich holding debt over commercial properties. The trick in the real estate industry is to maintain an income that pays for the debt, and this is the same mindset that can be applied to technical debt.

Have your programmers identify the areas of the project that weigh upon the rest of the project the least. You may have a relatively large amount of technical debt in a single module or function, but that module or function may not be used throughout the rest of the program very much. If the technical debt from one of these modules turns into a bonafide error, that error is at least manageable and non-critical.

The one critique of this “snowball programming” methodology is that this effort leads to more efficiency in the least important parts of the project. The team can fix this by identifying mission critical functions and modules as early in the process as possible, and looking for ways to employ these functions throughout the programming. This may require an extra layer of strategizing before actually sitting down to code, but it is well worth it at the start of the project, when you have the most time available to the team.

Estimate the percentage of bulk that can be allowed into mission critical functions and less important functions. Give this benchmark to your programmers from the beginning of the process, so they will have a quantifiable number to work towards. As time winds down, they will naturally include this productivity benchmark alongside their other key performance metrics instead of trying to include efficiency as a last minute addition to the process.

Stop worrying about the technical debt boogeyman in the shadows of your coding. If you set a precedent before the project begins, you will have a benchmark that will help you predict the efficiency of your programming efforts. You may not be able to get rid of technical debt completely, but you can control it while maintaining your schedule and budget!

JavaScript Error Handling

JavaScript Error Handling – InternalError: too much recursion

Today in our continued journey through our JavaScript Error Handling series, we’re examining the InternalError object known as the Recursion error.

Below we’ll explore the cause of a Recursion error in JavaScript, as well as how to manage and avoid this error in your own projects, so let’s begin!

The Technical Rundown

  • All JavaScript error objects are descendants of the Error object, or an inherited object therein.
  • The InternalError object is inherited from the Error object.
  • The Recursion error is a specific type of InternalError object.

When Should You Use It?

As the name of the Recursion error implies, this error will pop up when the JavaScript engine detects an excessive level of recursion. The challenge with properly capturing and designing around hitting this recursive limit is trying to estimate what the JavaScript engine deems to be “excessive”.

As you’ll likely recall, recursion occurs anytime a function calls itself during execution. Typically this is done as a means of iterating over a collection of some type, until a specific criteria is met, and then the recursive behavior is halted and execution continues on.

For our simple example, we’ll be performing a basic countdown in the console.log, starting from the initial argument value down to zero:

This produces an expected output in the console.log of:

With this simple function, it’s easy to see when and how our recursion will fail out, exiting the recursive process. In this case, it’s when value > 0 is false; that is, when value is 0 or less.

Increasing the level of recursion, which in our example case means simply increasing our starting argument above 10, we can start to push the envelope of the JavaScript engine and produce a Recursion error.

The difficulty, as previously mentioned, is determining how much recursion is considered excessive and will throw our Recursion error in any given JavaScript engine.

Let’s modify our countdown example above to help us handle any potential errors we get, and then start upping the number of recursions until we break something.

Here we’re trying 10000 recursions. Note: We’ve commented out the console.log output for now, just so we don’t output thousands of items:

As discussed, this behaves differently depending on the JavaScript engine. In Firefox 50, this produces a Recursion error of the explicit type we expected (InternalError):

On the other hand, Chrome 54 handles it just fine. With a bit of testing, we can actually determine that each browser version has different limits on the level of allowed recursion. Below you’ll find that Firefox 46 can handle up to 7705 recursions, but number 7706 produces a Recursion error. This number increases slightly for Firefox 50, while Chrome 54 allows for a much higher level of recursion before it gets upset and errors out.

Browser Acceptable Limit Excessive Limit
Firefox 46 7705 7706
Firefox 50 7718 7719
Chrome 54 31416 31417

The bottom line when planning around and dealing with potential Recursion errors is to limit the potential iterations to a manageable number that never approaches these limits. Generally speaking, as we look back in time at older generations of browsers, these limits are smaller and smaller, so a developer creating a site for all users and platforms should plan for the worst case scenario.

To help you along the way in your journey towards JavaScript error handling perfection, be sure to check out Airbrake’s JavaScript Error Handling Software!


500 Internal Server Error: What It Is And How To Fix It

People who develop and maintain web applications usually dread a 500 Internal Server Error. This isn’t because these errors are usually hard to fix, however. It’s because the error is usually not specific and can occur for a number of different reasons. The best way to debug the error depends upon the server and what’s actually running at the time. Consider some debugging tips to help diagnose and fix common causes of this problem.

Diagnosing a 500 Internal Server Error

It’s important to note that the server side of an application generates this error even though you may see the error code inside your browser. That means that your HTML, client-side JavaScript, or anything else that runs in a browser is not the source of a 500 Internal Server Error. Of course, the name does imply that it’s a server error, but systems have grown so complex today, that this reminder could be helpful.

Debugging Common Platforms

Is the server running a common software set like WordPress, Joomla, or Drupal? Obviously, production versions of well-tested software like this should not cause a 500 Internal Server Error if everything is set correctly. It still happens because of incompatible versions, bad installations, or server permissions that were not set correctly.

These are some common problems that might cause an error like this with a popular and well-used software platform:

  • If the software was just upgraded to a new version, it’s likely that the upgrade failed and needs to be refreshed. There may be instructions to help with this on the vendor’s website. If the software was just installed, something may have failed in the installation process.
  • If a new plugin or theme was just activated, it’s probably a good idea to roll that change back and try again. Even well-tested plugins might conflict with other plugins in the installation.
  • If the software has been upgraded, older plugins or themes might not be compatible with the upgrade. The only course of action is to start deactivating things until the error goes away. That doesn’t directly solve the problem; however, it will find the culprit. It might be possible to get the plugin developer to release an update.
  • The host may not have permissions set correctly. Alternatively, there might be a problem with the directory’s .htaccess file. Scripts, files, or other resources can’t be accessed, so the host just displays a general error.

When common software scripts and packages generate a 500 Internal Server Error, the best place to look for general answers is on the support sites for these platforms. If this error has happened to one user, it has probably happened to multiple users, has been reported upon, and has generated discussion. Of course, it usually happens because of certain circumstances, so it’s important to look for help with an idea of what might have changed or gone wrong since the last time the software ran correctly.

Debugging Server-Side Scripts

This problem might also occur because of a custom script that is just getting developed and tested. In order to find and debug the issue, consider some common solutions to the dreaded 500 Internal Server Error:

  • Server permission: Very commonly, incorrect permissions on a file or folder that contains one of the scripts causes this this error. The script isn’t throwing the error because the server can’t even run the script. Check to see what the permissions should be and ensure that’s how they are set on the server.
  • Script timeout: A PHP or other server-side script may have timed out. This could be because of a programming error that put the script in an endless loop or a resource that wasn’t available.
  • Server timeout: If the server was busy, needed to be rebooted, or the connection was lost, the script might still report a 500 Internal Server Error. It’s possible that the error might not happen the next time. This is still something to check out. If a script times out during testing, it’s likely to do it again during production when it’s accessed by more users.
  • Errors in .htaccess files: Occasionally, an error in the coding of an .htaccess file may cause this error. Certainly, it’s a good idea to check this file if none of the situations listed above apply.
  • Errors in a script: If a custom script generated the error, it might be possible to get that script to offer some more specific information. For example, a PHP script could have display_errors turned on in order to either send specific errors to a log file or display them on the screen. Other server-side languages have similar functionality. The runtime environment might have defaulted to hide errors from users, but this isn’t helpful for debugging.

Get Help From a Server Administrator

In some cases, developers don’t have control over everything in their server’s environment. If the script runs on a third-party host, that host might help in a few different ways:

  • Look for documentation that is specific to the server about common reasons for this error. Different operating systems and even different configurations may generate this error for a variety of reasons.
  • Ask the server provider to help by accessing error logs that may contain more clues. For example, the technician or administrator should be able to find out if the server happened to be busy or down when the browser reported the error. This may be the only way to solve some intermittent errors.

Typically, a 500 Internal Server Error is Easy to Fix

Really, in most cases, very simple problems cause this error. These problems are very easy to fix. The issue is that the error is so general that finding the bug can sometimes seem like looking for a needle in a haystack. It’s typically easiest to resolve this error if the software developer or tester can remember what conditions changed to start causing the error.

Keep in mind, that these changes may have been made by someone other than the developer — like a host administrator. If nothing has truly changed, it’s likely that the host itself caused the error because the environment was incompatible with software or there were performance problems.

Ruby Exception Handling

Ruby Exception Handling: Error Class Hierarchy

Ruby exception handling classes dramatically simplify exception management. At the top-most level of the Ruby exception class hierarchy resides the Exception class, the monolithic parent class of over a half-dozen subclasses which typically regulate the grunt work of Ruby exception handling.

Below is the entire list of built-in subclasses of the Exception class:

  • NoMemoryError
  • ScriptError
    • LoadError
    • NotImplementedError
    • SyntaxError
  • SecurityError
  • SignalException
    • Interrupt
  • StandardError -- default for rescue
    • ArgumentError
      • UncaughtThrowError
    • EncodingError
    • FiberError
    • IOError
      • EOFError
    • IndexError
      • KeyError
      • StopIteration
    • LocalJumpError
    • NameError
      • NoMethodError
    • RangeError
      • FloatDomainError
    • RegexpError
    • RuntimeError -- default for raise
    • SystemCallError
      • Errno::*
    • ThreadError
    • TypeError
    • ZeroDivisionError
  • SystemExit
  • SystemStackError
  • fatal – impossible to rescue

Below we’ll briefly examine each of the top-level subclasses of Exception to easily define when and why they might be used for Ruby exception handling during normal execution.


NoMemoryError is raised when memory allocation fails and the application must halt.


ScriptError is a superclass which is raised when a runtime error occurs which is caused by failure of the script to execute as expected. This may be due to invalid required file path or simple syntax errors. Subclasses of ScriptError include LoadErrorNotImplementedError, and SyntaxError.


SecurityError is raised when execution attempts a potentially unsafe operation. This most commonly occurs when the $SAFE variable is raised above the default level of 0, which informs Ruby that it can execute potentially insecure code.

For example, the following code raises a SecurityError exception, due to calling the insecure untaint operation:


SignalException is raised when a signal is received upon a running process and contains only one subclass, Interrupt. A SignalException can be captured with something like the following snippet:


StandardError, as the name implies, is the most common or standard type of exception Ruby will raise. While most applications will attempt to capture or raise a specific subclass of StandardError (such as ArgumentErrorEncodingError, etc), StandardError itself will be raised when a rescue clause is executed without any explicit Exception class specified:


SystemExit is raised when the exit method is called. For example:



SystemStackError is raised when a stack overflow occurs. This most commonly occurs when an infinite loop is generated. For example, running the following:

OutputSystemStackError: stack level too deep.


fatal exceptions are raised when Ruby encounters a fatal error that requires it to exit. Unlike most other Exception subclasses, fatal errors cannot be rescued.