4

As far as I know, Governor limits can not be suppressed and will be shown to user on the UI. However I am facing below scenario where SOQL 101 limit is being logged into debug log and not being shown in the UI.

  1. User converts the lead.
  2. Account, Opportunity, Contact created.
  3. User is successfully redirected to newly created account page.
  4. All the references are correct. Like ConvertedAccountId, convertedOpptyId etc.

When I go to the Debug logs, There SOQL 101 (System.LimitException: Too many SOQL queries: 101) is being shown. If dig more in the debug logs then I found that this exception came while Opportunity Before Update trigger.

The question is, Since all this is happening in single context, then how this governor limit is not being reported to UI, and being shown only in Debug log.

has anybody felt it before ? or is this some known issue ? or I am missing something ?

4
  • Is the SOQL statement inside a try-catch block? If you're catching the exception and not re-throwing it or otherwise handling the error, the root error wouldn't be shown to the end user. Commented Aug 4, 2014 at 5:55
  • 3
    That is applicable to exceptions other then Governor limit exceptions. I think that governor limit exceptions can't be suppressed, even if we put try-catch it will be shown to user.
    – byadav
    Commented Aug 5, 2014 at 10:55
  • possible duplicate of System.Exception: Too many SOQL queries: 101 Commented Aug 11, 2014 at 9:48
  • Hi Christian, its not duplicate, since Here I am asking why governor limit is being suppressed and not being displayed to end users, while other thread discuss about how to avoid this governor limit.
    – byadav
    Commented Aug 21, 2014 at 4:06

2 Answers 2

4

It sounds to me like the code being executed and hitting this limit is occuring in an asychonous context. If it's in a method marked @future or in batch apex then the error would not be surfaced to the UI.

@future methods are reasonably common with lead conversion due to the way that record ownership is handled (see example use case here):

Documentation says :- " If you have a trigger set to fire when new records are created, the trigger temporarily assigns a system user as the owner of the created records. After the trigger finishes, the owner is set to the lead owner. "

Anything that you want to do in which you are involving the lead owner should be done in future class.

4
  • 1
    This is correct as the standard Lead Convert process uses a number of @future calls to do it's work. Commented Aug 15, 2014 at 9:01
  • 1
    Just want to add one thing is you can increase the number of SOQL now for future method with the following code : @future(limits='2xSOQL') OR @future(limits='3xSOQL')
    – brovasi
    Commented Aug 15, 2014 at 9:19
  • Hi, I agree that asyncronous method comes into picture when governor exception is being shown only in Debug logs and not on UI. However I confirm that there is no future method call involved and I can see only one log generated for 'leadconvert.jsp'. If it would have been on different context or in future method then two or more different debug logs would have been generated.
    – byadav
    Commented Aug 21, 2014 at 4:09
  • But the code for leadconvert is not necessarily running in the same context as the user's session.
    – Matt Lacey
    Commented Aug 21, 2014 at 4:51
-5

Few things keep in mind to avoid "System.LimitException: Too many SOQL queries: 101" are:

The first thing you can do is to limit you SOQL query using limit clause. For example,

select id, name from contact limit 100

We should use DML operations must be used out of the for loops and you need to use a list for the update or delete.

All the triggers fired will be counted in a single context or call. We need to ensure that total number of SOQL fired should be less than 100. In order to by pass this, you need to change your code in such a way that SOQL fired must be less than 100 or if you need to change the context then you can use @future annotation which will run the code asynchronously.

You need to make sure that the SOQL query you are using should not be inside the for loop.

There are certain best practices which you would have to follow to avoid this error (to avoid hitting governor limit).

  1. http://wiki.developerforce.com/page/Best_Practice:_Avoid_SOQL_Queries_Inside_FOR_Loops

  2. http://salesforcedeveloperblog.blogspot.com/2011/05/best-practices-of-triggers.html

  3. http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_bestpract.htm

  4. http://wiki.developerforce.com/page/Apex_Code_Best_Practices

If you follow the above practices, the error will stop. Moreover there is no way wherein we in Salesforce can increase the governor limit or can stop it so best practices need to be followed.

1
  • Hi, I was not asking for avoiding governor limit or best practices. I asked, why governor limit is being suppressed, while it should never be suppressed, not even by try-catch blocks.
    – byadav
    Commented Aug 5, 2014 at 11:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .