Not able to catch an exception (Custom + Standard) from trigger

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
2
down vote

favorite

1

Please consider the below scenario:

1. I have an Application__c object.


2. I have a trigger on that (for simplicity, coded directly in trigger) which does one thing if the record name is Error then throws exception.

---

trigger ApplicationTrigger on Application__c (before insert, after update)

 if(trigger.new[0].Name == 'Error')
 Application__c application;
 System.debug(application.Name);
 

3. 
   

   Now I am running below code:

   
   
   

   

   
   

Now notice the catch statement is not executing, means system was not able to catch the exception. It came as the Fatal Error.

This is kind of a big issue where if there is null pointer or any other exception in trigger and exception handling code will not be able to do anything. Not even logging since it never reaches to catch block.

Let me know if you guys ever faced such situation and if yes what you did to make sure that it is properly caught.

apex exception

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

add a comment | 

up vote
2
down vote

favorite

1

Please consider the below scenario:

1. I have an Application__c object.


2. I have a trigger on that (for simplicity, coded directly in trigger) which does one thing if the record name is Error then throws exception.

---

trigger ApplicationTrigger on Application__c (before insert, after update)

 if(trigger.new[0].Name == 'Error')
 Application__c application;
 System.debug(application.Name);
 

3. 
   

   Now I am running below code:

   
   
   

   

   
   

Now notice the catch statement is not executing, means system was not able to catch the exception. It came as the Fatal Error.

This is kind of a big issue where if there is null pointer or any other exception in trigger and exception handling code will not be able to do anything. Not even logging since it never reaches to catch block.

Let me know if you guys ever faced such situation and if yes what you did to make sure that it is properly caught.

apex exception

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

add a comment | 

up vote
2
down vote

favorite

1

up vote
2
down vote

favorite

1

1

Please consider the below scenario:

1. I have an Application__c object.


2. I have a trigger on that (for simplicity, coded directly in trigger) which does one thing if the record name is Error then throws exception.

---

trigger ApplicationTrigger on Application__c (before insert, after update)

 if(trigger.new[0].Name == 'Error')
 Application__c application;
 System.debug(application.Name);
 

3. 
   

   Now I am running below code:

   
   
   

   

   
   

Now notice the catch statement is not executing, means system was not able to catch the exception. It came as the Fatal Error.

This is kind of a big issue where if there is null pointer or any other exception in trigger and exception handling code will not be able to do anything. Not even logging since it never reaches to catch block.

Let me know if you guys ever faced such situation and if yes what you did to make sure that it is properly caught.

apex exception

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

Please consider the below scenario:

1. I have an Application__c object.


2. I have a trigger on that (for simplicity, coded directly in trigger) which does one thing if the record name is Error then throws exception.

---

trigger ApplicationTrigger on Application__c (before insert, after update)

 if(trigger.new[0].Name == 'Error')
 Application__c application;
 System.debug(application.Name);
 

3. 
   

   Now I am running below code:

   
   
   

   

   
   

Now notice the catch statement is not executing, means system was not able to catch the exception. It came as the Fatal Error.

This is kind of a big issue where if there is null pointer or any other exception in trigger and exception handling code will not be able to do anything. Not even logging since it never reaches to catch block.

Let me know if you guys ever faced such situation and if yes what you did to make sure that it is properly caught.

apex exception

apex exception

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

share|improve this question

share|improve this question

edited 2 hours ago

sfdcfox

227k10174389

edited 2 hours ago

sfdcfox

227k10174389

edited 2 hours ago

sfdcfox

227k10174389

227k10174389

asked 2 hours ago

Kiran Machhewar

2,130820

asked 2 hours ago

Kiran Machhewar

2,130820

asked 2 hours ago

Kiran Machhewar

2,130820

2,130820

add a comment | 

add a comment | 

1 Answer
1

active

oldest

votes

up vote
2
down vote

Try-catch spanning trigger transactions has been exceptionally unreliable for about a year now (if not longer). Some time ago, you used to be able to catch the correct type of exception (e.g. a NullPointerException would be just that), while I noticed either last year or early this year that any exception in a trigger would be converted to a DmlException instead, the original error lost. Now, it appears that any unhandled exception in a trigger immediately terminates the transaction, with the status code for the log showing that exception.

I'm going to check with some people over at salesforce.com and bring this up, see if it's an intentional change, or if there needs to be a bug logged. For now, the best advice I can offer you is this: do not allow exceptions to leave your current code context (e.g. a trigger) unless you're intentionally trying to terminate the transaction. Each code unit should be responsible for handling its own exceptions. If you need to report an error, always use the addError method to report the error back to the calling context.

This is really a best practice anyways. Exceptions should be exceptional (or ideally, never), and when/if they do happen, they should be handled as close to the source as possible. Always try to write code that won't generate exceptions, particularly NullPointerException, ListException, QueryException, MathException, and TypeException. All of these exceptions are easily avoidable and/or can be handled in the immediate vicinity of where they can occur.

---

Edit: I built a unit test for this, and the code worked as expected. Here's the trigger and unit test for context:

---

trigger q232645 on Lead (before insert) 
 if(Trigger.new[0].LastName == 'Exception') 
 Lead record;
 // This line here generates a NullPointerException...
 record.LastName = 'Test';
 

---

@isTest class q232645Test 
 @isTest static void test() 
 try 
 insert new lead(LastName='Exception');
 System.assert(false, 'Should not reach here; trigger should throw exception.');
 catch(Exception e) 
 System.debug('We should see this in the logs.');
 return;
 
 System.assert(false, 'We should not get this far because of the return statement.');
 

---

This unit test passes, despite the execute anonymous code not working. I'm convinced this is a bug, and I'll do my best to have some one look in to this for you.

share|improve this answer

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you @sfdcfox for giving light on this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
  – sfdcfox
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  -- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  

 | 
show 4 more comments

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f232645%2fnot-able-to-catch-an-exception-custom-standard-from-trigger%23new-answer', 'question_page');

);

Post as a guest

Name Email

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
2
down vote

Try-catch spanning trigger transactions has been exceptionally unreliable for about a year now (if not longer). Some time ago, you used to be able to catch the correct type of exception (e.g. a NullPointerException would be just that), while I noticed either last year or early this year that any exception in a trigger would be converted to a DmlException instead, the original error lost. Now, it appears that any unhandled exception in a trigger immediately terminates the transaction, with the status code for the log showing that exception.

I'm going to check with some people over at salesforce.com and bring this up, see if it's an intentional change, or if there needs to be a bug logged. For now, the best advice I can offer you is this: do not allow exceptions to leave your current code context (e.g. a trigger) unless you're intentionally trying to terminate the transaction. Each code unit should be responsible for handling its own exceptions. If you need to report an error, always use the addError method to report the error back to the calling context.

This is really a best practice anyways. Exceptions should be exceptional (or ideally, never), and when/if they do happen, they should be handled as close to the source as possible. Always try to write code that won't generate exceptions, particularly NullPointerException, ListException, QueryException, MathException, and TypeException. All of these exceptions are easily avoidable and/or can be handled in the immediate vicinity of where they can occur.

---

Edit: I built a unit test for this, and the code worked as expected. Here's the trigger and unit test for context:

---

trigger q232645 on Lead (before insert) 
 if(Trigger.new[0].LastName == 'Exception') 
 Lead record;
 // This line here generates a NullPointerException...
 record.LastName = 'Test';
 

---

@isTest class q232645Test 
 @isTest static void test() 
 try 
 insert new lead(LastName='Exception');
 System.assert(false, 'Should not reach here; trigger should throw exception.');
 catch(Exception e) 
 System.debug('We should see this in the logs.');
 return;
 
 System.assert(false, 'We should not get this far because of the return statement.');
 

---

This unit test passes, despite the execute anonymous code not working. I'm convinced this is a bug, and I'll do my best to have some one look in to this for you.

share|improve this answer

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you @sfdcfox for giving light on this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
  – sfdcfox
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  -- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  

 | 
show 4 more comments

up vote
2
down vote

Try-catch spanning trigger transactions has been exceptionally unreliable for about a year now (if not longer). Some time ago, you used to be able to catch the correct type of exception (e.g. a NullPointerException would be just that), while I noticed either last year or early this year that any exception in a trigger would be converted to a DmlException instead, the original error lost. Now, it appears that any unhandled exception in a trigger immediately terminates the transaction, with the status code for the log showing that exception.

I'm going to check with some people over at salesforce.com and bring this up, see if it's an intentional change, or if there needs to be a bug logged. For now, the best advice I can offer you is this: do not allow exceptions to leave your current code context (e.g. a trigger) unless you're intentionally trying to terminate the transaction. Each code unit should be responsible for handling its own exceptions. If you need to report an error, always use the addError method to report the error back to the calling context.

This is really a best practice anyways. Exceptions should be exceptional (or ideally, never), and when/if they do happen, they should be handled as close to the source as possible. Always try to write code that won't generate exceptions, particularly NullPointerException, ListException, QueryException, MathException, and TypeException. All of these exceptions are easily avoidable and/or can be handled in the immediate vicinity of where they can occur.

---

Edit: I built a unit test for this, and the code worked as expected. Here's the trigger and unit test for context:

---

trigger q232645 on Lead (before insert) 
 if(Trigger.new[0].LastName == 'Exception') 
 Lead record;
 // This line here generates a NullPointerException...
 record.LastName = 'Test';
 

---

@isTest class q232645Test 
 @isTest static void test() 
 try 
 insert new lead(LastName='Exception');
 System.assert(false, 'Should not reach here; trigger should throw exception.');
 catch(Exception e) 
 System.debug('We should see this in the logs.');
 return;
 
 System.assert(false, 'We should not get this far because of the return statement.');
 

---

This unit test passes, despite the execute anonymous code not working. I'm convinced this is a bug, and I'll do my best to have some one look in to this for you.

share|improve this answer

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you @sfdcfox for giving light on this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
  – sfdcfox
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  -- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  

 | 
show 4 more comments

up vote
2
down vote

up vote
2
down vote

Try-catch spanning trigger transactions has been exceptionally unreliable for about a year now (if not longer). Some time ago, you used to be able to catch the correct type of exception (e.g. a NullPointerException would be just that), while I noticed either last year or early this year that any exception in a trigger would be converted to a DmlException instead, the original error lost. Now, it appears that any unhandled exception in a trigger immediately terminates the transaction, with the status code for the log showing that exception.

I'm going to check with some people over at salesforce.com and bring this up, see if it's an intentional change, or if there needs to be a bug logged. For now, the best advice I can offer you is this: do not allow exceptions to leave your current code context (e.g. a trigger) unless you're intentionally trying to terminate the transaction. Each code unit should be responsible for handling its own exceptions. If you need to report an error, always use the addError method to report the error back to the calling context.

This is really a best practice anyways. Exceptions should be exceptional (or ideally, never), and when/if they do happen, they should be handled as close to the source as possible. Always try to write code that won't generate exceptions, particularly NullPointerException, ListException, QueryException, MathException, and TypeException. All of these exceptions are easily avoidable and/or can be handled in the immediate vicinity of where they can occur.

---

Edit: I built a unit test for this, and the code worked as expected. Here's the trigger and unit test for context:

---

trigger q232645 on Lead (before insert) 
 if(Trigger.new[0].LastName == 'Exception') 
 Lead record;
 // This line here generates a NullPointerException...
 record.LastName = 'Test';
 

---

@isTest class q232645Test 
 @isTest static void test() 
 try 
 insert new lead(LastName='Exception');
 System.assert(false, 'Should not reach here; trigger should throw exception.');
 catch(Exception e) 
 System.debug('We should see this in the logs.');
 return;
 
 System.assert(false, 'We should not get this far because of the return statement.');
 

---

This unit test passes, despite the execute anonymous code not working. I'm convinced this is a bug, and I'll do my best to have some one look in to this for you.

share|improve this answer

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

Try-catch spanning trigger transactions has been exceptionally unreliable for about a year now (if not longer). Some time ago, you used to be able to catch the correct type of exception (e.g. a NullPointerException would be just that), while I noticed either last year or early this year that any exception in a trigger would be converted to a DmlException instead, the original error lost. Now, it appears that any unhandled exception in a trigger immediately terminates the transaction, with the status code for the log showing that exception.

I'm going to check with some people over at salesforce.com and bring this up, see if it's an intentional change, or if there needs to be a bug logged. For now, the best advice I can offer you is this: do not allow exceptions to leave your current code context (e.g. a trigger) unless you're intentionally trying to terminate the transaction. Each code unit should be responsible for handling its own exceptions. If you need to report an error, always use the addError method to report the error back to the calling context.

This is really a best practice anyways. Exceptions should be exceptional (or ideally, never), and when/if they do happen, they should be handled as close to the source as possible. Always try to write code that won't generate exceptions, particularly NullPointerException, ListException, QueryException, MathException, and TypeException. All of these exceptions are easily avoidable and/or can be handled in the immediate vicinity of where they can occur.

---

Edit: I built a unit test for this, and the code worked as expected. Here's the trigger and unit test for context:

---

trigger q232645 on Lead (before insert) 
 if(Trigger.new[0].LastName == 'Exception') 
 Lead record;
 // This line here generates a NullPointerException...
 record.LastName = 'Test';
 

---

@isTest class q232645Test 
 @isTest static void test() 
 try 
 insert new lead(LastName='Exception');
 System.assert(false, 'Should not reach here; trigger should throw exception.');
 catch(Exception e) 
 System.debug('We should see this in the logs.');
 return;
 
 System.assert(false, 'We should not get this far because of the return statement.');
 

---

This unit test passes, despite the execute anonymous code not working. I'm convinced this is a bug, and I'll do my best to have some one look in to this for you.

share|improve this answer

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

share|improve this answer

share|improve this answer

edited 1 hour ago

edited 1 hour ago

edited 1 hour ago

answered 1 hour ago

sfdcfox

227k10174389

answered 1 hour ago

sfdcfox

227k10174389

answered 1 hour ago

sfdcfox

227k10174389

227k10174389

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you @sfdcfox for giving light on this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
  – sfdcfox
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  -- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  

 | 
show 4 more comments

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Thank you @sfdcfox for giving light on this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
  – sfdcfox
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  -- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
  – Kiran Machhewar
  1 hour ago
  

  
  
  
  

Thank you @sfdcfox for giving light on this.
– Kiran Machhewar
1 hour ago

Thank you @sfdcfox for giving light on this.
– Kiran Machhewar
1 hour ago

But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
– Kiran Machhewar
1 hour ago

But I am not completely aligned with the concept of handling exception as close to the source as possible, because here just for example I used null pointer. But in my application/code base I use Custom Exception heavily to stop the execution like when I don't find custom setting record or some data is required other wise there is no point in going further in code and such failure/exception situations code be anywhere in code. So exception makes most sense, but with the above problem looks like I am not able to log or properly notify to the user about the error.
– Kiran Machhewar
1 hour ago

Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
– Kiran Machhewar
1 hour ago

Let me add more to this, I have a web service which is called from third party and I make sure that I give the error status code if the webservice code gets an exception and comes in catch block and I return the message also. Sometimes third party system could miss some values or sufficient data might not be present in my side only so I use Exceptions, it worked out really well, I had full confidence that no matter what (except uncatchable exceptions), I would be able to log the message and return the proper error but now as the control is not coming in catch, I am not respond error to other
– Kiran Machhewar
1 hour ago

@KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
– sfdcfox
1 hour ago

@KiranMachhewar Exceptions should be used as sparingly as possible for performance reasons. There are times to use them, but definitely not to try and transmit data across a DML-transaction barrier.
– sfdcfox
1 hour ago

-- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
– Kiran Machhewar
1 hour ago

-- continue other system and nor I am able to do my custom logging. Again thank you for looking into this.
– Kiran Machhewar
1 hour ago

 | 
show 4 more comments

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f232645%2fnot-able-to-catch-an-exception-custom-standard-from-trigger%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email