I know that Future methods cannot be called from another future method But Why? Please explain why this constraint/limitation exists on their use.
closed as off-topic by Markus Slabina, Ratan Paul, battery.cord, Santanu Boral, Dave Humm Jul 19 '17 at 13:43
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Question that are intended to propose ideas, solicit opinion or provoke discussion are better asked in an alternative forum." – Markus Slabina, Ratan Paul, battery.cord, Santanu Boral, Dave Humm
If an @future method could be called from another @future method, one could have a chain of indeterminate length or even create a loop that would extend the execution a transaction indefinitely through a very complex maze of additional execution contexts. Tracing the transaction to completion could become very complex. This would be what's considered an "anti-pattern".
By limiting @future methods to a single call, the execution context is limited to at most two execution contexts. The possibility of creating an infinite loop that can't be resolved doesn't exist. If an @future method could call another @future method, the platform couldn't easily resolve a transaction to completion.
Yes, you can't call them. It's a default limitation.
Reason: All future methods are Asynchronous but not all async calls are future. If I had to take a guess, it's to keep the system from being flooded with forked calls (look at the bash fork bomb for what could happen). Future methods are asynchronous and it holds resources. Allowing multiple future invocations might make program dependable on resources and also on Data since it's not guaranteed when program will run.
However you can write
Invocable method using
@InvocableMethod annotation and invoke it from Process builder. By using this way you can overcome default limitation.
Future methods were designed in a different era of Salesforce technology. There were far fewer computing resources available, future methods had separate governor limits from Batchable, and Queueable did not yet exist. We also had a limit of a mere 10 future methods per Apex transaction, instead of the more generous 50 that we have today. The limitation of not being able to call a future method from another future method was put in place to prevent consuming the relatively scarce resources of the platform years ago.
Today, while we have expanded limits and more resources available, the limits remain as they were. The reasons previously would have been because of resource limits, but today, the reasons are strictly historical. If you need to chain asynchronous calls, you can use Queueable methods instead. Since there's already another means of indefinitely chaining methods (via Queueable), salesforce.com hasn't had a need to lift the restriction from future methods. The previous code still works, and they'd rather not introduce bugs by patching a feature to add the ability to chain future methods.