I read about Page Reference, and the documentation states the usage of Page Reference:

  • To view or set query string parameters and values for a page

  • To navigate the user to a different page as the result of an action method

But when I go through some code examples it seems like developers code it like this:

  public PageReference retrievePlan(){

     //logic bla bla
     return null;

Why does this code use PageReference as a return type while it only returns null? Can we just use public void retrievePlan instead of PageReference and returning null? Does doing this have any significance?

  • 3
    You have no idea how long I've wanted someone to ask this question. – sfdcfox Jan 14 '15 at 2:37
  • 1
    I use it if there is a error i return null otherwise new page. – Shanker Paudel Sep 1 '16 at 9:14

There seem to be two cases where developers use this pattern. The first case is the developer learns about action methods for the first time, and is led to believe they must use a PageReference return type for the function to work, since nearly all tutorials seem to do this. The second case is where a developer does this because they want to have the return type already set "just in case they need it later."

The truth is, this is a bad practice, and should be avoided. First, many developers come to rely on the method's return type to quickly figure out what the method's output will be. Seeing a return type of PageReference will trick developers into thinking a possible redirect could occur. This later gets codified into test methods, and so becomes reinforced.

It might not seem like a big deal when there are only five lines of code, but if a method contains two hundred lines of code, it becomes difficult to diagnose when something needs to be fixed. Or, a later developer might break something, assuming the return type is intentional, and changes the null to some PageReference.

There is no valid use for this anti-pattern, and you should never return a value when the result is always null. This also applies to other types of methods; never return a type if you only intend to return null.

  • 1
    Can't emphasise your first point enough. I was taught that was how they worked when I first got started, took a couple of years before I realised you didn't need to return a PageReference. I – Matt Lacey Jan 14 '15 at 7:22
  • Good answer. I never saw this addressed in any documentation, and example code that I've seen consistently uses PageReference for all actions. – Jeremy Nottingham Apr 11 '15 at 15:51

If we assume an action method is a method invoked via some action= attribute on a VF page, then

  • When an action method returns null, it indicates to VF that the current page should be refreshed (such as when displaying errors or simply doing some ajax action)
  • When an action method returns a non null PageReference, then typically this indicates navigation to a different page (perhaps a new page in a multi-step wizard or a server-side redirection to a new page altogether)

Personally, I always declare my action methods as returning PageReference by convention but there are clearly examples where an action method won't navigate to a new page, and, as you've noted throughout SFSE, such methods are declared as void and work just fine

Note that the VF doc (Defining Action methods) does state the following in an example:

The save method ...takes the standard signature for an action method: it is public, returns a PageReference, and contains no arguments


Update - I see sfdcfox has weighed in here with a better answer

  • 1
    It's more about verb use, I suppose. For example, a function named redirect() had best return a PageReference in at least one instance. Conversely, I wouldn't expect initializeExtension() to redirect, and I'd argue it should be a void return type. Contrast JavaScript's confirm() built-in versus Windows ShowDialog() built-in. Confirm is something you'd expect to get a result from, but ShowDialog also returns a result. Why? Because ShowDialog is actually a "confirm" function. Poor function naming is just as bad as non-obvious return values. – sfdcfox Jan 14 '15 at 6:13
  • 1
    One use case for returning null is when an action should redirect, and is expected to according to it's name like you say, but then some validation reason prevents that redirect from occuring. Granted in this case you should split it up into two actions potentially but I think for some scenarios it's a legit reason. Doesn't justify doing returning null when you don't do any such checking of course :) – Matt Lacey Jan 14 '15 at 7:27
  • I'll have to admit that when I saw the line in the VF doc 'The save method ...takes the standard signature for an action method: it is public, returns a PageReference, and contains no arguments' - I went 'all in' and declared all my action methods as return type PageReference even when the verb would not indicate navigation to a new page. @LaceySnr's example is something that occurs commonly for me - an action method, say, doClone() that does DML and redirects to a new page on success but if there's an error, returns null after creating an apexPages.Message. – cropredy Jan 14 '15 at 17:34

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.