Write a comment...
0/9000
ublic static boolean isPrimeNumber(integer toTest) {
if (toTest == null) throw new IllegalArgumentException('null');
if (toTest <= 1) return false;
if (toTest == 2) return true;
if (Math.mod(toTest, 2) == 0) return false;
integer boundary = (integer)Math.Floor(Math.Sqrt(toTest));
for (integer i = 3; i <= boundary; i += 2) {
if (Math.mod(toTest, i) == 0) {
return false;
}
}
return true;
}
Thanks @[Chris Peterson] for introducing apex switch..I was exploring switch and playing around and was thinking why not when block can support list<sObject>..for example
for(sObject sob : lsitofobject){
switch on sob {
when account cr {
cr=[select id,SLAExpirationDate__c from account limit 1]; //Good that I am working on only one acocunt
if(cr.Date__c!=null){
integer Month = cr.Date__c.month();
}
}
when List<contact> co {
co=[select id from contact ];
}
}
}
A List<SObject> isn't an sObject, so how would that work with lsitofobject?
You might find the List<sobject>.getSObjectType() method useful here.
A thank you to everybody who helped provide comments on the proposal in this group - we're now working on the technical implementation of switch. You're welcome to continue to comment, but at this point we're focusing on the implementation details and are unlikely to change the design more for the initial release.
With that said, the feedback from the community did have a substantial impact on the final plans for what we're going to deliver. As a result the proposed specification linked in the sidebar doesn't quite match at this point; stay tuned for details on what it will look like in its final form.
I've raised a couple of ideas that would help with utilizing the new switch statement support.
The first is to help with determining trigger context. This would be useful, especially for newer devs to make it clear that the trigger is only ever executing in one of those states at a time.
A Trigger Context Enum to represent the current operation and before/after state

As a fan of functional programming, what I'd like to see -- even more than a switch that works exactly like Java (my second choice) -- would be one that works like the match expression in Scala.
https://alvinalexander.com/scala/using-match-expression-like-switch-statement
Advantages:
1. You don't need the "break" statements which make Java code noisy (I've never found the fall-through to be desirable behaviour).
2. You get a return value which facilitates better testing.
Would love to see this target a fully generalised 'case if <expression> [<alias>]{}'. The overhead of having to remember special rules for what is/is not allowed in a case is going to reduce the developer value.
To get there you could perhaps handle the 'case if Account a' by introducing a joint instanceof and cast operator that is shorthand for ‘<expression> instanceof Account ? (Account)<expression> : null’ rather than building it into switch.
I think getting rid of fallthrough is an excellent idea. Does it have any kind of multiple-execution support? For example,
Integer i = 4;
switch on i using {
case if 4 {
System.debug('Hit 4: ' + i);
}
case if 4, 5 {
System.debug('Hit 4,5:' + i);
}
}
Output:
Hit 4: 4
Hit 4,5: 4
What happens in this case? Does it fail to compile because you specified 4 twice, or does it support it fine but only execute one? Or does it run both?
limiting to literals for strings/integer seems too restrictive as it is not uncommon to have static final variables so various points in and out of the class can reference common expression without worrying about the actual literal value:
e.g.
final static String STAGE_NEW = 'New';
final static String STAGE_QUOTED = 'Quoted';
switch on oppo.stageName using
case if STAGE_NEW {
System.debug('stage new');
}
case if STAGE_QUOTED {
System.debug('stage quoted');
}
case else {
System.debug('default');
}