I was reading through Future Method Documentation and found that you can only return void type with this method, is there any particular reason that method returns void type ?

  • 1
    Answer is simple because it is asynchronous process.. For example if you run future method from synchronous process then you can't wait to complete asynchronous process and get that value from asynchronous process in trigger context.. – Ratan Paul Mar 5 '16 at 10:55
  • How on earth do you expect a synchronous process to get a return from an asynchronous process. Have your main process just run for days? – Jesse Milburn Mar 5 '16 at 19:41
  • The @future methods can only have primitive data types (or collections of them) for their input parameters. As they run at a future time from when they are called, they have nowhere to return a response and thus can only return a void type. Other than this and the fact that there is a limit as to how many future methods can be invoked at any one time, they look and behave like any other method. – Andy Hitchings Apr 25 '16 at 16:28

Future methods will run in the future. You don't want your synchronous code waiting an unknown period of time for an asynchronous bit of code to finish working.

The whole point is you want to clearly separate what happens now from what happens in the future.

By only returning void, you can't have code that waits for a result.

It's also why you can only pass Ids and primitives as parameters. It's assumed the future method will execute at an unknown time in the future, so if you need database records you'll need to re-query the data to ensure it's fresh.

| improve this answer | |
  • 1
    You can pass any primitive or collection thereof, not just Id. – Adrian Larson Mar 5 '16 at 14:49
  • Sorry, that's what happens when you post after a few beers :) Updated the answer accordingly. – Nick Cook Mar 5 '16 at 22:49

(I can't add a comment under Nick as my rep is low, but...)

To add to Nick Cook's answer,

There is a relatively new interface in Salesforce (Oct '14?), Queueable, which works the same as @future. That is, the platform queues up a process when the line of code is executed, and runs it at a later time in a separate execution.

Some key differences, and reasons why you should know about Queueable as well as @future -

  • A queueable process can queue another queueable, or launch an @future. Future methods cannot call future methods
  • Future methods can queue queueables
  • You can pass in non-primitive data types when you create a queueable object

This can be useful for either of the following -

  1. You need to recreate some multi-step process - for example, something that may require a rolling refresh through the UI, as a non-UI process
  2. You need a stateful queued process. For example, you can construct a queueable with your current controller and when the queued process starts, it already has the state of the controller at the time you queued the process

Here's more info about Queueables: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm

Note: With a little Apex Magic, you could have a future handler class which delegates between @future and Queueable, and using this class you can always make a callouut or queue another future process. As far as I can see, this requires that you pass information as primitive data.

Note2: Queueable itself is not always able to make callouts, so to fully leverage, you'll need both Queueables and @futures.

| improve this answer | |
  • Can we make call out to external web service through Queueable interface ? – MIX DML Mar 6 '16 at 4:12
  • 3
    @PrabhatKumar yep just implement Database.AllowCallouts. – Adrian Larson Mar 6 '16 at 14:35

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.