Summer’18: Rethink Trigger Logic with Apex Switch

With 17,110 points on the IdeaExchange idea, the arrival of the switch statement in Apex in the Summer’18 release is an exciting addition to the language that should please many developers.

About switch

As a language construct, switch comes in a number of forms in many languages. You might have seen a similar logical construct referred to as case, select, or some other things. The mouthful of a technical definition of switch is a multiway branch logical control flow feature. If you don’t want to spend time parsing that, it’s basically a syntax structure to evaluate a variable against many possible values without having a bunch of repetitive else if blocks. It can reduce repetitive code and improve clarity and readability of logical code paths.

Switch in Apex

Each implementation of this feature in each language needs to work for that language. Apex is no different — key point here being Apex is not a general purpose programming language. It is a Salesforce domain-specific language solving problems for developers working with the Lightning Platform.

One minor obstacle is that Apex greatly resembles Java, which uses the syntax switch…case. Because of this resemblance, many developers expect Apex to follow Java syntax and conventions. Only trouble is in Apex the word “case” already represents the class for the Case sObject. Even if the compiler could be made to cope with a keyword of “case” alongside a class called Case, it isn’t going to help the cause of readability or clear clean code. So although Apex resembles Java in many ways, the when keyword is preferred (Largely based on feedback from early beta testers in the Trailblazer community group). Here is a basic representation of the syntax with a String variable being compared to String literals:

switch on someStringVar { when ‘value 1’ { //…do something… } when ‘value 2’, ‘value 3’ { //…do some other thing } when ‘value 4’ { //…do this thing… } when else { //…under all other circumstances } }

Those of you who have used a version of switch statement in the C-family of languages will immediately notice the absence of a break statement in each when block.

If you really did take notice, good job!

That’s because in Apex there is no fall-through. This means the first logical branch is executed, then no others. In other words, the first executed branch blocks any following branches in the switch block.

The last Apex-specific feature I’ll mention is the types that you are allowed to switch on. Unremarkably, String, Integer and Long can all be compared to a literal value. But there are also sObject identifier and enum comparisons. These bring some new prospects to how a developer might now structure their code, especially in triggers.

Switch on sObject type

Allowing to evaluate when based on sObject type is exciting. Let’s consider a result set from a custom object, where we have queried the Owner field. Owner is polymorphic in a custom object, meaning it