Adding a System.debug changes code behavior2019 Community Moderator ElectionWhat is a use case where one would use an SObject as a Map key?Map/Set size when sobjects are duplicatedDebug Filter option which only list System.debug statements?System.debug not appearing in logs from test methodDateTime.format() unexpected behaviorHas anybody seen this behavior? Batch jobs failing silently on CPU timeout except in certain circumstancesAutomatically Remove System.debug statements from Apex Code?Apex Subscript value not valid on second submissionUnexpected results when using a custom class as key in MapSystem.debug not showing up in salesforce trigger executionSystem.debug prints twice
Is there a name for this algorithm to calculate the concentration of a mixture of two solutions containing the same solute?
How do you respond to a colleague from another team when they're wrongly expecting that you'll help them?
Does a 'pending' US visa application constitute a denial?
Is there a working SACD iso player for Ubuntu?
Request info on 12/48v PSU
What should you do if you miss a job interview (deliberately)?
Are the IPv6 address space and IPv4 address space completely disjoint?
Multiplicative persistence
Freedom of speech and where it applies
Closed-form expression for certain product
How can "mimic phobia" be cured or prevented?
Electoral considerations aside, what are potential benefits, for the US, of policy changes proposed by the tweet recognizing Golan annexation?
Is this toilet slogan correct usage of the English language?
Delivering sarcasm
What are the purposes of autoencoders?
How much character growth crosses the line into breaking the character
Why should universal income be universal?
Where does the bonus feat in the cleric starting package come from?
I am looking for the correct translation of love for the phrase "in this sign love"
Fear of getting stuck on one programming language / technology that is not used in my country
Pre-mixing cryogenic fuels and using only one fuel tank
Is it possible to have a strip of cold climate in the middle of a planet?
Writing bit difficult equation in latex
Character escape sequences for ">"
Adding a System.debug changes code behavior
2019 Community Moderator ElectionWhat is a use case where one would use an SObject as a Map key?Map/Set size when sobjects are duplicatedDebug Filter option which only list System.debug statements?System.debug not appearing in logs from test methodDateTime.format() unexpected behaviorHas anybody seen this behavior? Batch jobs failing silently on CPU timeout except in certain circumstancesAutomatically Remove System.debug statements from Apex Code?Apex Subscript value not valid on second submissionUnexpected results when using a custom class as key in MapSystem.debug not showing up in salesforce trigger executionSystem.debug prints twice
I have the following code
Map<Account, Integer> accountsMap = new Map<Account, Integer>();
Account a = new Account();
accountsMap.put(a, 1);
a.name='Bob';
//System.debug(accountsMap);
System.debug(accountsMap.get(a));
System.assertEquals(1, accountsMap.get(a));
Debug in the sixth line shows null
which is expected and next assert fails. However if I uncomment debug in the fifth line I will get the following log(note that there is no assert failure):
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
As noticed in the comments, to reproduce this you have to set the debug level for Apex to anything below FINEST
. On FINEST
level assert always fails.
apex map debug
add a comment |
I have the following code
Map<Account, Integer> accountsMap = new Map<Account, Integer>();
Account a = new Account();
accountsMap.put(a, 1);
a.name='Bob';
//System.debug(accountsMap);
System.debug(accountsMap.get(a));
System.assertEquals(1, accountsMap.get(a));
Debug in the sixth line shows null
which is expected and next assert fails. However if I uncomment debug in the fifth line I will get the following log(note that there is no assert failure):
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
As noticed in the comments, to reproduce this you have to set the debug level for Apex to anything below FINEST
. On FINEST
level assert always fails.
apex map debug
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level toFINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.
– Oles Malkov
yesterday
add a comment |
I have the following code
Map<Account, Integer> accountsMap = new Map<Account, Integer>();
Account a = new Account();
accountsMap.put(a, 1);
a.name='Bob';
//System.debug(accountsMap);
System.debug(accountsMap.get(a));
System.assertEquals(1, accountsMap.get(a));
Debug in the sixth line shows null
which is expected and next assert fails. However if I uncomment debug in the fifth line I will get the following log(note that there is no assert failure):
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
As noticed in the comments, to reproduce this you have to set the debug level for Apex to anything below FINEST
. On FINEST
level assert always fails.
apex map debug
I have the following code
Map<Account, Integer> accountsMap = new Map<Account, Integer>();
Account a = new Account();
accountsMap.put(a, 1);
a.name='Bob';
//System.debug(accountsMap);
System.debug(accountsMap.get(a));
System.assertEquals(1, accountsMap.get(a));
Debug in the sixth line shows null
which is expected and next assert fails. However if I uncomment debug in the fifth line I will get the following log(note that there is no assert failure):
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
As noticed in the comments, to reproduce this you have to set the debug level for Apex to anything below FINEST
. On FINEST
level assert always fails.
apex map debug
apex map debug
edited yesterday
Oles Malkov
asked yesterday
Oles MalkovOles Malkov
1,7363822
1,7363822
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level toFINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.
– Oles Malkov
yesterday
add a comment |
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level toFINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.
– Oles Malkov
yesterday
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level to
FINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.– Oles Malkov
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level to
FINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.– Oles Malkov
yesterday
add a comment |
3 Answers
3
active
oldest
votes
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:
class Bucket<U>
Integer hashCode;
U[] values;
public class Map<T, U>
List<Bucket<U>> buckets = new List<Bucket<U>>();
public U put(T key, U value)
Integer hashCode = value.hashCode();
Bucket<U> temp;
for(Bucket<U> bucket: buckets)
if(bucket.hashCode == hashCode)
temp = bucket;
// hash not found, make new bucket
if(temp == null)
buckets.add(temp = new Bucket<U>());
temp.hashCode = hashCode;
for(Integer i = 0; i < temp.values.size(); i++)
if(temp.values[i].equals(value))
U result = temp.values[i];
temp.values[i] = value;
return result; // Returns old value
temp.values.add(value); // Adds new value to bucket
Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.
The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.
When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.
This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.
As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.
Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
|
show 9 more comments
UPDATE
The below answer is applicable only when the Log Level for Apex is set to FINEST.
The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.
Here's my observation.
If I run the exact code you have where you are adding the Name
after adding the object in Map, I never get the debug returning 1.
accountsMap.put(a, 1);
a.name='Bob';
I get it as:
08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null
Now, this is the expected behavior based on documentation (emphasis mine):
Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.
Things work as expected if you will have any system.debug
or not, only if you have it added as this:
a.name='Bob';
accountsMap.put(a, 1);
As noted in the documentation, exercise caution while using SObjects as keys for maps.
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
add a comment |
Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.
When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).
For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.
You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.
Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254891%2fadding-a-system-debug-changes-code-behavior%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:
class Bucket<U>
Integer hashCode;
U[] values;
public class Map<T, U>
List<Bucket<U>> buckets = new List<Bucket<U>>();
public U put(T key, U value)
Integer hashCode = value.hashCode();
Bucket<U> temp;
for(Bucket<U> bucket: buckets)
if(bucket.hashCode == hashCode)
temp = bucket;
// hash not found, make new bucket
if(temp == null)
buckets.add(temp = new Bucket<U>());
temp.hashCode = hashCode;
for(Integer i = 0; i < temp.values.size(); i++)
if(temp.values[i].equals(value))
U result = temp.values[i];
temp.values[i] = value;
return result; // Returns old value
temp.values.add(value); // Adds new value to bucket
Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.
The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.
When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.
This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.
As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.
Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
|
show 9 more comments
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:
class Bucket<U>
Integer hashCode;
U[] values;
public class Map<T, U>
List<Bucket<U>> buckets = new List<Bucket<U>>();
public U put(T key, U value)
Integer hashCode = value.hashCode();
Bucket<U> temp;
for(Bucket<U> bucket: buckets)
if(bucket.hashCode == hashCode)
temp = bucket;
// hash not found, make new bucket
if(temp == null)
buckets.add(temp = new Bucket<U>());
temp.hashCode = hashCode;
for(Integer i = 0; i < temp.values.size(); i++)
if(temp.values[i].equals(value))
U result = temp.values[i];
temp.values[i] = value;
return result; // Returns old value
temp.values.add(value); // Adds new value to bucket
Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.
The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.
When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.
This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.
As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.
Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
|
show 9 more comments
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:
class Bucket<U>
Integer hashCode;
U[] values;
public class Map<T, U>
List<Bucket<U>> buckets = new List<Bucket<U>>();
public U put(T key, U value)
Integer hashCode = value.hashCode();
Bucket<U> temp;
for(Bucket<U> bucket: buckets)
if(bucket.hashCode == hashCode)
temp = bucket;
// hash not found, make new bucket
if(temp == null)
buckets.add(temp = new Bucket<U>());
temp.hashCode = hashCode;
for(Integer i = 0; i < temp.values.size(); i++)
if(temp.values[i].equals(value))
U result = temp.values[i];
temp.values[i] = value;
return result; // Returns old value
temp.values.add(value); // Adds new value to bucket
Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.
The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.
When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.
This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.
As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.
Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.
Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?
Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:
class Bucket<U>
Integer hashCode;
U[] values;
public class Map<T, U>
List<Bucket<U>> buckets = new List<Bucket<U>>();
public U put(T key, U value)
Integer hashCode = value.hashCode();
Bucket<U> temp;
for(Bucket<U> bucket: buckets)
if(bucket.hashCode == hashCode)
temp = bucket;
// hash not found, make new bucket
if(temp == null)
buckets.add(temp = new Bucket<U>());
temp.hashCode = hashCode;
for(Integer i = 0; i < temp.values.size(); i++)
if(temp.values[i].equals(value))
U result = temp.values[i];
temp.values[i] = value;
return result; // Returns old value
temp.values.add(value); // Adds new value to bucket
Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.
The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.
When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.
This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.
As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.
Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.
answered yesterday
sfdcfoxsfdcfox
261k12207452
261k12207452
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
|
show 9 more comments
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
When you force a System.debug -- this doesn't have an effect at least in this case. What OP has currently never returns value for me, which is the expected behavior at least per the documentation.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
I have the exact code as OP has with no debug statements commented and it fails as expected. Only when I switch adding the name before adding the object in map, and with all other code as-is, it works perfectly fine. I was using anonymous window.
– Jayant Das
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@JayantDas Sorry, just realized that this code in the example results in a null value. That's just how things get "lost." It's entirely possible that the map will partially or fully fix itself depending on its contents. Try adding a key where name = null, then another where name = bob, then change the account where name = null to name = bob, and then debug. You'll see a different behavior.
– sfdcfox
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@sfdcfox Thanks, that is what I was looking for. Now I'm just curious is there any other way to "refresh a map state" other than System.debug? I assume this can be considered as a "hack" and one should not use such things in production code? Also, you said that you are using sObjects as map keys so how do you ensure their hash is not spoiled, I assume just do not modify the key once it was put in the map? Thanks
– Oles Malkov
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
@OlesMalkov (a) JSON.serialize I think also "fixes" a map/set (b) it is undocumented behavior, certain a "hack" to avoid in production, (c) I always construct a new "key" before using get/set; I make sure to never modify the original key material. See this answer for an example usage of this technique. Notice how I consider the keys immutable by always constructing new keys every time I need one.
– sfdcfox
yesterday
|
show 9 more comments
UPDATE
The below answer is applicable only when the Log Level for Apex is set to FINEST.
The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.
Here's my observation.
If I run the exact code you have where you are adding the Name
after adding the object in Map, I never get the debug returning 1.
accountsMap.put(a, 1);
a.name='Bob';
I get it as:
08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null
Now, this is the expected behavior based on documentation (emphasis mine):
Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.
Things work as expected if you will have any system.debug
or not, only if you have it added as this:
a.name='Bob';
accountsMap.put(a, 1);
As noted in the documentation, exercise caution while using SObjects as keys for maps.
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
add a comment |
UPDATE
The below answer is applicable only when the Log Level for Apex is set to FINEST.
The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.
Here's my observation.
If I run the exact code you have where you are adding the Name
after adding the object in Map, I never get the debug returning 1.
accountsMap.put(a, 1);
a.name='Bob';
I get it as:
08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null
Now, this is the expected behavior based on documentation (emphasis mine):
Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.
Things work as expected if you will have any system.debug
or not, only if you have it added as this:
a.name='Bob';
accountsMap.put(a, 1);
As noted in the documentation, exercise caution while using SObjects as keys for maps.
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
add a comment |
UPDATE
The below answer is applicable only when the Log Level for Apex is set to FINEST.
The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.
Here's my observation.
If I run the exact code you have where you are adding the Name
after adding the object in Map, I never get the debug returning 1.
accountsMap.put(a, 1);
a.name='Bob';
I get it as:
08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null
Now, this is the expected behavior based on documentation (emphasis mine):
Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.
Things work as expected if you will have any system.debug
or not, only if you have it added as this:
a.name='Bob';
accountsMap.put(a, 1);
As noted in the documentation, exercise caution while using SObjects as keys for maps.
UPDATE
The below answer is applicable only when the Log Level for Apex is set to FINEST.
The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.
Here's my observation.
If I run the exact code you have where you are adding the Name
after adding the object in Map, I never get the debug returning 1.
accountsMap.put(a, 1);
a.name='Bob';
I get it as:
08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null
Now, this is the expected behavior based on documentation (emphasis mine):
Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.
Things work as expected if you will have any system.debug
or not, only if you have it added as this:
a.name='Bob';
accountsMap.put(a, 1);
As noted in the documentation, exercise caution while using SObjects as keys for maps.
edited yesterday
answered yesterday
Jayant DasJayant Das
16.9k21230
16.9k21230
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
add a comment |
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
Just because there's a warning about using them doesn't mean it's not a good practice when used appropriately.
– sfdcfox
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
If you are too sure that your object does not change, then yes. But in scenario as this one where the field value was added after the key was added, it gets difficult to maintain. Good Practice anyways is a very much debated thing as far as I can say. I would rather frame practice as consideration as noted in the documentation.
– Jayant Das
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
No, I'm just saying that the documentation doesn't use the word "practice" at all. It's neither a Good Practice nor Bad Practice, just that some caution must be taken when using this technique. It's the same as with C/C++'s "pointers," a lot of people say its a "bad practice" to use pointers because they can crash the code, while others, like me, simply state you shouldn't be using them if you don't know what you're doing. The technique is perfectly safe and usable as long as one understands what goes on under the hood. The Bad Practice here is using it the wrong way.
– sfdcfox
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
Agreed. I actually edited the verbiage in the answer. Ah, you remind me about the pointers -- was one of my favorites :)
– Jayant Das
yesterday
1
1
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
@sfdcfox, if I was writing Java still (rather than Apex) I would never use a mutable object as a key in a map. This really is bad practice because you open your application up to hard-to-find and hard-to-fix bugs. It is great that the Salesforce docs actually state caution should be taken. IMHO it would have been far better if Apex could make an object used as a key in a map (including an SObject) immutable. Any subsequent attempt to write to fields of that object would immediately throw an exception and prevent difficult to trace issues occurring later. Or provide a general immutable lock.
– Phil W
yesterday
add a comment |
Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.
When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).
For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.
You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.
Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
add a comment |
Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.
When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).
For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.
You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.
Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
add a comment |
Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.
When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).
For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.
You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.
Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.
Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.
When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).
For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.
You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.
Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.
edited yesterday
answered yesterday
Phil WPhil W
481210
481210
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
add a comment |
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
Hey Phil, thanks for your answer but as I said in my question I know that this is a bad practice. I have just used the above example as it is a good illustration of this System.debug issue and I'm not looking for any workaround.
– Oles Malkov
yesterday
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254891%2fadding-a-system-debug-changes-code-behavior%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
if I both comment 5 and 6th debug line, assert fails. Also, if I uncomment any of the 5 or 6th line, assert fails.
– Santanu Boral
yesterday
@SantanuBoral thank you for the check. I've tried changing debug level and when I set Apex level to
FINEST
it also fails with all debug statements uncommented, however on lower levels (FINER/FINE/DEBUG/...
) it still passes the assert.– Oles Malkov
yesterday