Order of execution for Visualforce page Get requests

The code originally quoted is a bad example, because we do actually know what the values of selectedValue and editMode will be; with a private setter, editMode won't have a value until set by the other setter. However, consider this controller:

public class CompCont { public String a { get; set { a = (b == null)? 'Hello': value } } public String b { get; set; } } 

What will {!a} evaluate to, assuming {!a} and {!b} are both assigned a value using apex:attribute? The answer, of course, is that we don't know, because the compiler could choose to call set(b) first, which will cause 'a' to take its assigned value, while if set(a) is called first, 'a' will take on the value 'Hello' instead of the other value.

You could test this code out, and get the correct output one day, then try it two weeks later, and get the wrong output. It could even have different behavior across orgs on different servers (e.g. production versus sandbox). This is a very difficult and subtle error to try and figure out.

Here's a related question that shows why you should be careful about considering how code executes:

Controller

public class componentController1 { public componentController1() { counter = 0; } public integer counter { get; set; } public string b { get; set { b = value; counter++; } } public string a { get; set { a = value; counter++; } } } 

Component

<apex:component controller="componentController1"> <apex:attribute assignTo="{!a}" name="valueA" description="First Part" type="String" /> <apex:attribute assignTo="{!b}" name="valueB" description="Second Part" type="String" /> {!a} {!b} {!counter} </apex:component> 

What will the value of counter be? Should it not be 2? After all, we perform just one assignment each to a and b, right? As it turns out, the correct answer is 4, not 2 (at least, in my org, today). Each setter is called twice in my example, even with no form elements at the page level. Later optimizations might reduce the count to 2, or increase it to 6 (or really, any value of at least 2).

Any action you perform in a getter or setter should be idempotent, meaning it must have exactly the same effect if the method is called once or a dozen times. This also usually means caching query results if you use lazy loading (e.g. this example would have cost four queries without caching, instead of two).

You should generally leave data manipulation for action methods and constructors, where you have greater control over the order that methods are called in.