The preceding examples have shown the use of the service class methods from Visualforce Controller methods. Let's take a closer look at what is happening here, the assumptions being made, and also at an Apex Scheduler example. Other examples of service methods in action, such as from a Lightning Component, will feature throughout later chapters.

The following code represents code from a controller class utilizing StandardController that provides support for the Visualforce page associated with a Custom Button on the Race object. Notice how it wraps the record ID in Set, honoring the bulkified method signature:

public PageReferenceawardPoints(){
  try{
    RaceService.awardChampionshipPoints(new Set<Id> {standardController.getId() });
  }

  catch (Exception e){
    ApexPages.addMessages(e);
  }
  return null;
}

The constructor of these controllers is not shown, but it essentially stores StandardController or StandardSetController in a member variable for later reference by the controller methods.

The following code outlines a similar version that can be used when StandardSetController is being used, in cases where a Custom Button is required on the objects' list view:

public PageReferenceawardPointsToRaces(){
  try {
    RaceService.awardChampionshipPoints(new Map<Id, SObject>(standardSetController.getRecords()).keySet() );
  }

  catch (Exception e){
    ApexPages.addMessages(e);
  } 
  return null;
}

The Map constructor in Apex will take a list of SObjects and automatically build a map based on the IDs of the SObjects passed in. Combining this with the keySet method allows for a quick way to convert the list of records contained in StandardSetController into a list of IDs required by the service method.

In both cases, any exceptions are routed to the apex:pageMessages component on the page (which should be one of the first things you should consider adding to a page) by calling the ApexPages.addMessages method that is passing in the exception.

Note that there is no need for the controller code to roll back changes made within the service that may have been made to object records up to the exception being thrown, since the controller is safe in the assumption that the service method has already ensured this is the case. This arrangement between the two is essentially a Separation of Concerns at work!

Finally, let's look at an example from the SeasonNewsletterScheduler class. As with the controller example, it handles the exceptions itself, in this case, e-mails the user with any failures. Consider the following code:

global void execute(SchedulableContextsc) {
  try{
    SeasonService.issueNewsLetterCurrentSeason();
  }catch (Exception e){
    Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
    mail.setTargetObjectId(UserInfo.getUserId());
    mail.setSenderDisplayName(UserInfo.getUserName());
    mail.setSubject('Failed to send Season Newsletter'),
    mail.setHtmlBody(e.getMessage());
    mail.setSaveAsActivity(false);
    Messaging.sendEmail(new Messaging.SingleEmailMessage[] { mail });
  }
}