32

You need to take the namespace and enclosing class qualifiers off of the enum values. It knows what you mean because it know the type of the value you are switching on. So, you need to write it like this: Schema.DisplayType fieldType = getType(fieldName); switch on fieldType { when STRING { // do stuff } when CURRENCY { // do ...


17

According to Summer 18 Apex developer guide, 7 new Enum values are introduced in System.TriggerOperation class. AFTER_DELETE AFTER_INSERT AFTER_UNDELETE AFTER_UPDATE BEFORE_DELETE BEFORE_INSERT BEFORE_UPDATE Similarly, a new variable is added in Trigger class named as 'operationType, which stores the context enum it is executing in. Thus your trigger ...


15

Switch, like the if statement, is a tool. If can do whatever switch can do and more, but it can't do what switch does as efficiently as it does. Switch can drastically reduce the complexity of some code. Just to make a point, I'm going to show you a practical, very meaningful difference. Schema.DisplayType someType = someField.getDescribe().getType(); if( ...


11

The when values must be literals, so you cannot use String.valueOf as demonstrated in your second example. That said, using String.valueOf is approximately 10% more efficient when using literal string values: Long t3, t2, t1 = datetime.now().gettime(); for(Integer i = 0; i < 100000; i++) { sobjecttype a = account.sobjecttype; switch on a....


6

Switch is not a versioned feature, presumably because they didn't want to force developers to upgrade to the latest API just to take advantage of this (and potentially trigger a large number of other required changes). As I've said before (in a another answer on this site), consider keeping all your classes the same version to avoid bugs. Only upgrade your ...


4

I've noticed the same thing and can only assume that while there is a versioning layer in APIs, the compiler may just always grow its syntax and not shrink its syntax. Or it could be that there is a versioning mechanism there and the addition of that logic has just been missed. I've moved to version 43.0 to be on the safe side.


4

Switch statements, while welcome, are definitely still limited in functionality. It can't replace all possible situations you'd like to replace if-else statements with switch statements. Depending on your specific situation, you might be able to come up with a workaround. In your specific example, you'd write 'eventactions.fire', of course, but if you were ...


4

No, there's no case/switch syntax in AMPScript. You would need to use IF/ELSEIF/ENDIF statements to achieve the same result: %%[ var @value, @outcome set @value = RequestParameter('entered-value') IF @value == "Banana" THEN SET @outcome = "Yellow" ELSEIF @value == "Apple" THEN SET @outcome = "Red" ELSEIF @value == "Pear" ...


3

You can only use explicit string literals (no variables) in when blocks here. Note the documentation explicitly states a literal value must be used: When Blocks Each when block has a value that the expression is matched against. These values can take one of the following forms. when literal {} (a when block can have multiple, comma-separated literal ...


3

Why not declare a generic SobjectList outside the switch case statement? List<Sobject> listSobject = new List<Sobject>(); switch on objectName { when 'Account' { for(Account dynObject : (List<Account>)lstObjects) { listSobject.add(dynObject); } } when 'Contact' { for(Contact dynObject : (...


3

Just put the upsert inside your when blocks. List<Database.UpsertResult> results; switch on objectName { when 'Account' { List<Account> toUpsert = new List<Account>(); toUpsert.addAll(dynamicRecords); results = Database.upsert(toUpsert, externalIdField, /*allOrNone*/false); } when 'Address__c' { ...


2

This code: SObject[] sobs = [select Id, Name from Contact limit 5]; Database.upsert(sobs, Contact.Id, true); generates the error: Upsert with a field specification requires a concrete SObject type and this code does not: SObject[] sobs = [select Id, Name from Contact limit 5]; Database.upsert((Contact[]) sobs, Contact.Id, true); which is pretty ...


2

The accepted answer here Looping over a list of sObjects that has more than object type shows an Apex-specific extra capability of type matching that is kinda neat. Personally I'd rate a library feature like Comparator support above a language feature switch, but as I understand it, this was something of a test case to demonstrate that language enhancements ...


Only top voted, non community-wiki answers of a minimum length are eligible