when i write below in anonymous block,its executes successfully


In my Debug log i can see

03:56:52.045 (45470054)|USER_DEBUG|[3]|DEBUG|Name

I assume its standard Account class which is displaying field names? Does this have any practical application>


Indeed there are many practical use cases.

Here is one for your reference:


From the system.debug documentation:

If the msg argument is not a string, the debug method calls String.valueOf to convert it into a string. The String.valueOf method calls the toString method on the argument, if available, or any overridden toString method if the argument is a user-defined type. Otherwise, if no toString method is available, it returns a string representation of the argument.


Account.Name references a SObjectField. An SObjectField is a special token that gives you access to the field's properties by getDescribe(), and equally useful, it is a possible parameter to SObject.get and SObject.put, allowing some incredibly useful optimizations and generic code functions. Some examples that I've personally written elsewhere follow.

// Return a set of changed fields, given an old and new version of a record, e.g. in a trigger
public static Set<SObjectField> checkFieldChanges(SObject oldVal, SObject newVal, Set<SObjectField> fields) {
    Set<SObjectField> results = new Set<SObjectField>();
    for(SObjectField field: fields) {
        if(oldVal.get(field) != newVal.get(field)) {
    return results;

// Check if many fields are null
public static Boolean isAllNull(SObject record, Set<SObjectField> fields) {
    for(SObjectField field: fields) {
        if(record.get(field) != null) {
            return false;
    return true;

// Set many fields fields to a value
// Add error checking if you're concerned about data types
public static void setValues(SObject record, Set<SObjectField> fields, Object value) {
    for(SObjectField field: fields) {
        record.put(field, value);

Keep in mind that you could use get and put with string values, but field names can change if they're only dynamically referenced (e.g. an admin renames a field), and it also eliminates typos, as you can't reference a SObjectField that doesn't exist, and you also get to reduce error checking, because the fields are guaranteed to exist (but make sure they belong to the correct SObjectType!).

The last function, in particular, is great for clearing many fields to a null value, or setting many fields to a default value, such as zero. Do keep in mind that the value's type must be compatible with the field you're trying to set or you'll get an exception.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.