Like other programming languages, Apex includes a built-in class for exceptions. When your code exceeds a limit, an exception is thrown. For this reason, you really need to understand how exceptions work in Apex before we can go any further on limits. When the Salesforce1 Platform throws an exception, all statements that have been executed within that transaction are rolled back causing your entire attempt to execute code to fail. It's not fun to get an exception; it means that an end user is upset and you have more work to do.

Apex includes a generic exception class as well as over 20 types of specific exceptions for when various rules are broken. A lot of these specific exception types are easy to avoid such as don't divide by 0 when doing math, don't refer an index of a list that is out of bounds, and don't construct an account and then add it to a list of contacts. You get the picture. When your code does cause one of these exceptions, you can usually avoid it...

The Exception class includes various methods that help you better understand why an exception was thrown. You can even find out the type of exception, what line of Apex code caused the exception, and even get the entire stack trace. In addition to the built-in exception types, Apex includes the ability to create your own exception types. This allows you to catch a system exception, evaluate it, and throw your own custom exception. Although it involves slightly more work, a custom exception type can be the difference between frantically debugging code in the middle of the night and sleeping like a baby. Imagine writing code to integrate with an outside system. There are times where that process will fail (like when the other system is under maintenance). If you proactively throw your own exception, you'll immediately know why it failed. The following code will show you how to define a custom exception type:

//Define our custom Exception type
Public class myCustomException...

As we mentioned earlier, when you break an Apex limit, the Salesforce1 Platform throws an exception. It's actually a special type of exception called LimitException. A LimitException is a fatal one that you cannot handle gracefully with a try-catch block. When LimitException is thrown, all processing immediately ceases. The exception is appended to the debug log and an e-mail is sent out to the developer of that Apex class. Have faith though, it might not be possible to catch LimitException, but it is very possible to avoid it.

Apex includes an entire class dedicated to listing and measuring limits. It's no coincidence that the name of this class is Limits. It includes two methods for every limit in Apex. One method is to get the maximum number allowed for a limit, and the other method is to get the number that has already occurred. You can use the combination of both of these types of methods to ensure you never exceed the actual limit. The best part is...

Everyday Salesforce.com publishes the number of transactions that take place on their servers, and the average speed in which all those transactions take place at http://trust.salesforce.com. For years, the average speed has consistently been well under 300 milliseconds. This extremely fast speed has remained the same despite the number of transactions growing to nearly 2 billion (with a B) per day! In general, the page load time for web pages is usually calculated in seconds and not in milliseconds, and the same is true for pages on the Salesforce1 Platform. It doesn't take a rocket scientist to figure out then that for every page that loads in, say 3 seconds (a published best practice), there's got to be a very large number of transactions that are occurring in well under 300 milliseconds to balance it out. It's these extremely fast transactions that we care about because they are happening via Apex not through web page loads. It doesn't really matter how fast they...

Before we get too far into the Apex execution limits, we do need to bring up some other limits that you need to keep in mind. As we mentioned in the previous chapter, Apex is not a general programming language. It is specifically designed for use with the Salesforce1 Platform. While it might be technically possible to write code and build an application that behaves like the latest social networking website, a group coupon website, or even search engine, you shouldn't.

We're often approached by companies who want to copy an existing website or application. They select the Salesforce1 Platform for the backend because they know applications can be built on it very rapidly. What they don't know is that Salesforce and the Salesforce1 Platform are purchased on a per user subscription basis. It is much too cost prohibitive to purchase a license for every person in the world to access your service. We always try to break the bad news gently rather than take on the project. While we...

Customers of salesforce.com subscribe to a specific edition of the service. These editions exist across the various core applications (marketed as clouds) as well as the Salesforce1 Platform offering. The lowest priced edition always has the most restrictions. As you move up in price, these restrictions are reduced, but still exist. As a result of these restrictions, when you build an application on the Salesforce1 Platform, it's always a best practice to have as small of a footprint as possible so that any customer, regardless of the edition, can install your app.

Subscribers of the Salesforce core applications can install and execute code that references any of the objects included in those applications, such as opportunities, assets, or cases. Subscribers to just the Salesforce1 Platform don't have access to those objects and therefore can't install or execute code that references them. If you are building an application for the AppExchange app store, it's critical to determine...

The Salesforce1 Platform includes multiple robust APIs which can be utilized by external systems to integrate with Salesforce. These APIs include all the operations available in Apex such as querying record, inserting records, updating records, and so on. When developers new to Apex struggle with the limits, they often revert back to coding in other systems and calling one of the APIs. While this approach can certainly get the job done, it's typically not our preference and often results in future problems.

There is a limit on the number of inbound API calls that can be made to your Force.com org. This limit is partially based on the edition you are subscribed to and partially based on the number of licenses in your subscription. The minimum per 24-hour period is currently 5,000. There are 1,440 minutes in the day, so at first glance, it looks like you can synchronize with the Salesforce1 Platform every minute and still have plenty to spare. In reality though, it's much more complex...

From the beginning, salesforce.com has made it clear that they do not want their name associated with spam in any way. For this reason, there have always been limits on the number of mass e-mails you can send from the Salesforce1 Platform. However, a user can always send as many single e-mail messages (which can have multiple To, CC, and BCC recipients) as they can via the standard e-mail interface in the Salesforce GUI.

The mass e-mail limits vary based on the edition of your subscription. They are calculated in a rolling 24-hour period. This means that once you have sent the maximum number of mass e-mails allowed, you will have to wait a maximum of 24 hours before you can send more mass e-mails.

Apex includes the ability to send both single or mass e-mail messages. But since Apex can be used to programmatically send multiple single e-mail messages, the Salesforce1 Platform counts e-mail messages sent via Apex in your daily limit. Remember, the people behind Apex are very innovative...

We readily admit that this section header is a stretch (if you're not familiar with it, try searching for TARDIS on the Web), but there are only so many phrases related to time travel that can be replaced with the word limit. One of the amazing features of Apex is that it allows you to program back in time. Despite the fact that Apex and the Salesforce1 Platform are updated three times a year, Apex is fully backward compatible. In fact, you can write your code today under the current Apex limits, and then with a few keystrokes magically send your code back in time to a previous API version with historical limits.

Part of every Apex class is a bit of metadata that defines under which API version the code should run. This value stays set unless you modify it. That means that if your code behaves correctly today, it should continue to behave the exact same, even as the Salesforce1 Platform continues to be updated over time. This metadata is accessible in both...

We'll talk about triggers more in a later chapter, but for now you just need to know that a trigger is code that is automatically executed whenever a record is operated upon (meaning inserted, updated, deleted, or undeleted). When you first start programming in Apex, it tends to be trigger-related. These are usually simple scenarios such as when an account phone is modified, update the phone for all of the contacts on that account. This is shown in the following code:

//This code has a potentially fatal flaw in it
public static void updateContactAddresses(){
List<Contact> contactList = [
Select Id, Phone, AccountId, Account.Phone 
from Contact 
];
for ( Contact c : contactQuery ){
  c.Phone = c.Account.Phone;
}
update contactQuery;
}

Did you spot the flaw in the previous code block? If you tried it out in your Developer Edition org, it probably worked exactly as described. The problem doesn't lie in the syntax or logic.

A common mistake of new...