Exceptions and DML
It was to my understanding that when you throw an exception all previous operations are rolled back.
When an exception occurs, code execution halts and any DML
operations that were processed prior to the exception are rolled back
and aren’t committed to the database. Exceptions get logged in debug
logs.
I am running into a situation where I am able to insert a record in a logger class in the catch
and throw an exception after it. What gives?
The flow is: Class A calls Class B -> Class B calls Class C -> Class C has a webservice and a try/catch
public HttpResponse postTokenizer(String securityToken, String payloadJSON)
try
if (payloadJSON == null)
throw new GenericException('Tokenizer was called with no IDs. The ID must be either a Contact or Lead.');
HttpRequest tokenizerRequest = new HttpRequest();
tokenizerRequest.setMethod('POST');
tokenizerRequest.setEndpoint(tokensAPIEndpoint);
tokenizerRequest.setHeader('Authorization', 'token ' + securityToken);
tokenizerRequest.setHeader('Content-Type', 'application/json');
tokenizerRequest.setTimeout(30000);
tokenizerRequest.setBody(payloadJSON);
Http http = new Http();
HttpResponse response = http.send(tokenizerRequest);
if (!WebHelper.isSuccessStatus(response))
throw new GenericException('There has been an error calling the tokenizer service.');
return response;
catch(Exception e)
NFLogger.logError('TokenizerHelper, tokenizer', 'Call to postTokenizer() failed.', e); //todo:: how is this inserting????? shouldn't this be rolled back?
throw e;
NFLOGGER:
global with sharing class NFLogger
private enum LogLevel Error, Info
public static void logError(String tags, String errorMessage)
logMessage(logLevel.Error, tags, errorMessage, null);
public static void logError(String tags, String errorMessage, System.Exception ex)
logMessage(logLevel.Error, tags, errorMessage, ex);
public static void logInfo(String tags, String infoMessage)
logMessage(logLevel.Info, tags, infoMessage, null);
private static void logMessage(LogLevel level, String tags, String message, System.Exception ex)
try
LogMessage__c newMessage = new LogMessage__c(level__c = level.name(), tags__c = tags, message__c = message, exception__c = ex.getMessage());
insert newMessage;
catch (Exception e)
//intentionally we are ignoring "we suppress" any exception
//we need to guarantee that logMessage will never throw any exceptions
apex exception dml logging try-catch
add a comment |
It was to my understanding that when you throw an exception all previous operations are rolled back.
When an exception occurs, code execution halts and any DML
operations that were processed prior to the exception are rolled back
and aren’t committed to the database. Exceptions get logged in debug
logs.
I am running into a situation where I am able to insert a record in a logger class in the catch
and throw an exception after it. What gives?
The flow is: Class A calls Class B -> Class B calls Class C -> Class C has a webservice and a try/catch
public HttpResponse postTokenizer(String securityToken, String payloadJSON)
try
if (payloadJSON == null)
throw new GenericException('Tokenizer was called with no IDs. The ID must be either a Contact or Lead.');
HttpRequest tokenizerRequest = new HttpRequest();
tokenizerRequest.setMethod('POST');
tokenizerRequest.setEndpoint(tokensAPIEndpoint);
tokenizerRequest.setHeader('Authorization', 'token ' + securityToken);
tokenizerRequest.setHeader('Content-Type', 'application/json');
tokenizerRequest.setTimeout(30000);
tokenizerRequest.setBody(payloadJSON);
Http http = new Http();
HttpResponse response = http.send(tokenizerRequest);
if (!WebHelper.isSuccessStatus(response))
throw new GenericException('There has been an error calling the tokenizer service.');
return response;
catch(Exception e)
NFLogger.logError('TokenizerHelper, tokenizer', 'Call to postTokenizer() failed.', e); //todo:: how is this inserting????? shouldn't this be rolled back?
throw e;
NFLOGGER:
global with sharing class NFLogger
private enum LogLevel Error, Info
public static void logError(String tags, String errorMessage)
logMessage(logLevel.Error, tags, errorMessage, null);
public static void logError(String tags, String errorMessage, System.Exception ex)
logMessage(logLevel.Error, tags, errorMessage, ex);
public static void logInfo(String tags, String infoMessage)
logMessage(logLevel.Info, tags, infoMessage, null);
private static void logMessage(LogLevel level, String tags, String message, System.Exception ex)
try
LogMessage__c newMessage = new LogMessage__c(level__c = level.name(), tags__c = tags, message__c = message, exception__c = ex.getMessage());
insert newMessage;
catch (Exception e)
//intentionally we are ignoring "we suppress" any exception
//we need to guarantee that logMessage will never throw any exceptions
apex exception dml logging try-catch
Does it usePlatform Events
?
– Adrian Larson♦
Nov 12 '18 at 20:15
How doesNFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.
– Daniel Ballinger
Nov 12 '18 at 20:15
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20
add a comment |
It was to my understanding that when you throw an exception all previous operations are rolled back.
When an exception occurs, code execution halts and any DML
operations that were processed prior to the exception are rolled back
and aren’t committed to the database. Exceptions get logged in debug
logs.
I am running into a situation where I am able to insert a record in a logger class in the catch
and throw an exception after it. What gives?
The flow is: Class A calls Class B -> Class B calls Class C -> Class C has a webservice and a try/catch
public HttpResponse postTokenizer(String securityToken, String payloadJSON)
try
if (payloadJSON == null)
throw new GenericException('Tokenizer was called with no IDs. The ID must be either a Contact or Lead.');
HttpRequest tokenizerRequest = new HttpRequest();
tokenizerRequest.setMethod('POST');
tokenizerRequest.setEndpoint(tokensAPIEndpoint);
tokenizerRequest.setHeader('Authorization', 'token ' + securityToken);
tokenizerRequest.setHeader('Content-Type', 'application/json');
tokenizerRequest.setTimeout(30000);
tokenizerRequest.setBody(payloadJSON);
Http http = new Http();
HttpResponse response = http.send(tokenizerRequest);
if (!WebHelper.isSuccessStatus(response))
throw new GenericException('There has been an error calling the tokenizer service.');
return response;
catch(Exception e)
NFLogger.logError('TokenizerHelper, tokenizer', 'Call to postTokenizer() failed.', e); //todo:: how is this inserting????? shouldn't this be rolled back?
throw e;
NFLOGGER:
global with sharing class NFLogger
private enum LogLevel Error, Info
public static void logError(String tags, String errorMessage)
logMessage(logLevel.Error, tags, errorMessage, null);
public static void logError(String tags, String errorMessage, System.Exception ex)
logMessage(logLevel.Error, tags, errorMessage, ex);
public static void logInfo(String tags, String infoMessage)
logMessage(logLevel.Info, tags, infoMessage, null);
private static void logMessage(LogLevel level, String tags, String message, System.Exception ex)
try
LogMessage__c newMessage = new LogMessage__c(level__c = level.name(), tags__c = tags, message__c = message, exception__c = ex.getMessage());
insert newMessage;
catch (Exception e)
//intentionally we are ignoring "we suppress" any exception
//we need to guarantee that logMessage will never throw any exceptions
apex exception dml logging try-catch
It was to my understanding that when you throw an exception all previous operations are rolled back.
When an exception occurs, code execution halts and any DML
operations that were processed prior to the exception are rolled back
and aren’t committed to the database. Exceptions get logged in debug
logs.
I am running into a situation where I am able to insert a record in a logger class in the catch
and throw an exception after it. What gives?
The flow is: Class A calls Class B -> Class B calls Class C -> Class C has a webservice and a try/catch
public HttpResponse postTokenizer(String securityToken, String payloadJSON)
try
if (payloadJSON == null)
throw new GenericException('Tokenizer was called with no IDs. The ID must be either a Contact or Lead.');
HttpRequest tokenizerRequest = new HttpRequest();
tokenizerRequest.setMethod('POST');
tokenizerRequest.setEndpoint(tokensAPIEndpoint);
tokenizerRequest.setHeader('Authorization', 'token ' + securityToken);
tokenizerRequest.setHeader('Content-Type', 'application/json');
tokenizerRequest.setTimeout(30000);
tokenizerRequest.setBody(payloadJSON);
Http http = new Http();
HttpResponse response = http.send(tokenizerRequest);
if (!WebHelper.isSuccessStatus(response))
throw new GenericException('There has been an error calling the tokenizer service.');
return response;
catch(Exception e)
NFLogger.logError('TokenizerHelper, tokenizer', 'Call to postTokenizer() failed.', e); //todo:: how is this inserting????? shouldn't this be rolled back?
throw e;
NFLOGGER:
global with sharing class NFLogger
private enum LogLevel Error, Info
public static void logError(String tags, String errorMessage)
logMessage(logLevel.Error, tags, errorMessage, null);
public static void logError(String tags, String errorMessage, System.Exception ex)
logMessage(logLevel.Error, tags, errorMessage, ex);
public static void logInfo(String tags, String infoMessage)
logMessage(logLevel.Info, tags, infoMessage, null);
private static void logMessage(LogLevel level, String tags, String message, System.Exception ex)
try
LogMessage__c newMessage = new LogMessage__c(level__c = level.name(), tags__c = tags, message__c = message, exception__c = ex.getMessage());
insert newMessage;
catch (Exception e)
//intentionally we are ignoring "we suppress" any exception
//we need to guarantee that logMessage will never throw any exceptions
apex exception dml logging try-catch
apex exception dml logging try-catch
edited Nov 12 '18 at 20:21
asked Nov 12 '18 at 19:49
Olivia
1,286423
1,286423
Does it usePlatform Events
?
– Adrian Larson♦
Nov 12 '18 at 20:15
How doesNFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.
– Daniel Ballinger
Nov 12 '18 at 20:15
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20
add a comment |
Does it usePlatform Events
?
– Adrian Larson♦
Nov 12 '18 at 20:15
How doesNFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.
– Daniel Ballinger
Nov 12 '18 at 20:15
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20
Does it use
Platform Events
?– Adrian Larson♦
Nov 12 '18 at 20:15
Does it use
Platform Events
?– Adrian Larson♦
Nov 12 '18 at 20:15
How does
NFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.– Daniel Ballinger
Nov 12 '18 at 20:15
How does
NFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.– Daniel Ballinger
Nov 12 '18 at 20:15
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20
add a comment |
1 Answer
1
active
oldest
votes
The transaction will only be rolled back automatically if the thrown exception isn't caught.
Your example showed a call stack like:
- Class
A
calls ClassB
- Class
B
calls ClassC
- Class
C
attempts a callout to a webservice.- It catches any resulting exceptions,
- does DML to log the exception details,
- and then throws the exception again.
Since the resulting LogMessage__c
record exists after the transaction, there must be a catch
in either class B
or A
that is handling the exception thrown by class C
. This prevents the exception terminating the transaction and causing a rollback of any DML that had occured.
It looks like your quote came from Exceptions in Apex, What Happens When an Exception Occurs?. The last part of that paragraph clarifies that the transaction rollback is just for unhandled exceptions. It is probably a bit misleading to imply that a handled/caught exception would also cause a rollback.
What Happens When an Exception Occurs?
When an exception occurs, code execution halts. Any DML operations that were processed before the exception are rolled back and aren’t committed to the database. Exceptions get logged in debug logs. For unhandled exceptions, that is, exceptions that the code doesn’t catch, Salesforce sends an email that includes the exception information. The end user sees an error message in the Salesforce user interface.
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on thewebservice method
and on theroot method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?
– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what yourroot method
looks like. I assume it is on classA
and is the entry point for the transaction. Does it callNFLogger.logError()
and then not throw anything? That seems like the likely scenario here.
– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception inpostTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.
– Daniel Ballinger
Nov 12 '18 at 21:35
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239103%2fexceptions-and-dml%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The transaction will only be rolled back automatically if the thrown exception isn't caught.
Your example showed a call stack like:
- Class
A
calls ClassB
- Class
B
calls ClassC
- Class
C
attempts a callout to a webservice.- It catches any resulting exceptions,
- does DML to log the exception details,
- and then throws the exception again.
Since the resulting LogMessage__c
record exists after the transaction, there must be a catch
in either class B
or A
that is handling the exception thrown by class C
. This prevents the exception terminating the transaction and causing a rollback of any DML that had occured.
It looks like your quote came from Exceptions in Apex, What Happens When an Exception Occurs?. The last part of that paragraph clarifies that the transaction rollback is just for unhandled exceptions. It is probably a bit misleading to imply that a handled/caught exception would also cause a rollback.
What Happens When an Exception Occurs?
When an exception occurs, code execution halts. Any DML operations that were processed before the exception are rolled back and aren’t committed to the database. Exceptions get logged in debug logs. For unhandled exceptions, that is, exceptions that the code doesn’t catch, Salesforce sends an email that includes the exception information. The end user sees an error message in the Salesforce user interface.
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on thewebservice method
and on theroot method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?
– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what yourroot method
looks like. I assume it is on classA
and is the entry point for the transaction. Does it callNFLogger.logError()
and then not throw anything? That seems like the likely scenario here.
– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception inpostTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.
– Daniel Ballinger
Nov 12 '18 at 21:35
add a comment |
The transaction will only be rolled back automatically if the thrown exception isn't caught.
Your example showed a call stack like:
- Class
A
calls ClassB
- Class
B
calls ClassC
- Class
C
attempts a callout to a webservice.- It catches any resulting exceptions,
- does DML to log the exception details,
- and then throws the exception again.
Since the resulting LogMessage__c
record exists after the transaction, there must be a catch
in either class B
or A
that is handling the exception thrown by class C
. This prevents the exception terminating the transaction and causing a rollback of any DML that had occured.
It looks like your quote came from Exceptions in Apex, What Happens When an Exception Occurs?. The last part of that paragraph clarifies that the transaction rollback is just for unhandled exceptions. It is probably a bit misleading to imply that a handled/caught exception would also cause a rollback.
What Happens When an Exception Occurs?
When an exception occurs, code execution halts. Any DML operations that were processed before the exception are rolled back and aren’t committed to the database. Exceptions get logged in debug logs. For unhandled exceptions, that is, exceptions that the code doesn’t catch, Salesforce sends an email that includes the exception information. The end user sees an error message in the Salesforce user interface.
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on thewebservice method
and on theroot method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?
– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what yourroot method
looks like. I assume it is on classA
and is the entry point for the transaction. Does it callNFLogger.logError()
and then not throw anything? That seems like the likely scenario here.
– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception inpostTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.
– Daniel Ballinger
Nov 12 '18 at 21:35
add a comment |
The transaction will only be rolled back automatically if the thrown exception isn't caught.
Your example showed a call stack like:
- Class
A
calls ClassB
- Class
B
calls ClassC
- Class
C
attempts a callout to a webservice.- It catches any resulting exceptions,
- does DML to log the exception details,
- and then throws the exception again.
Since the resulting LogMessage__c
record exists after the transaction, there must be a catch
in either class B
or A
that is handling the exception thrown by class C
. This prevents the exception terminating the transaction and causing a rollback of any DML that had occured.
It looks like your quote came from Exceptions in Apex, What Happens When an Exception Occurs?. The last part of that paragraph clarifies that the transaction rollback is just for unhandled exceptions. It is probably a bit misleading to imply that a handled/caught exception would also cause a rollback.
What Happens When an Exception Occurs?
When an exception occurs, code execution halts. Any DML operations that were processed before the exception are rolled back and aren’t committed to the database. Exceptions get logged in debug logs. For unhandled exceptions, that is, exceptions that the code doesn’t catch, Salesforce sends an email that includes the exception information. The end user sees an error message in the Salesforce user interface.
The transaction will only be rolled back automatically if the thrown exception isn't caught.
Your example showed a call stack like:
- Class
A
calls ClassB
- Class
B
calls ClassC
- Class
C
attempts a callout to a webservice.- It catches any resulting exceptions,
- does DML to log the exception details,
- and then throws the exception again.
Since the resulting LogMessage__c
record exists after the transaction, there must be a catch
in either class B
or A
that is handling the exception thrown by class C
. This prevents the exception terminating the transaction and causing a rollback of any DML that had occured.
It looks like your quote came from Exceptions in Apex, What Happens When an Exception Occurs?. The last part of that paragraph clarifies that the transaction rollback is just for unhandled exceptions. It is probably a bit misleading to imply that a handled/caught exception would also cause a rollback.
What Happens When an Exception Occurs?
When an exception occurs, code execution halts. Any DML operations that were processed before the exception are rolled back and aren’t committed to the database. Exceptions get logged in debug logs. For unhandled exceptions, that is, exceptions that the code doesn’t catch, Salesforce sends an email that includes the exception information. The end user sees an error message in the Salesforce user interface.
edited Nov 12 '18 at 20:39
answered Nov 12 '18 at 20:32
Daniel Ballinger
71.9k15146386
71.9k15146386
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on thewebservice method
and on theroot method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?
– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what yourroot method
looks like. I assume it is on classA
and is the entry point for the transaction. Does it callNFLogger.logError()
and then not throw anything? That seems like the likely scenario here.
– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception inpostTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.
– Daniel Ballinger
Nov 12 '18 at 21:35
add a comment |
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on thewebservice method
and on theroot method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?
– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what yourroot method
looks like. I assume it is on classA
and is the entry point for the transaction. Does it callNFLogger.logError()
and then not throw anything? That seems like the likely scenario here.
– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception inpostTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.
– Daniel Ballinger
Nov 12 '18 at 21:35
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on the
webservice method
and on the root method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?– Olivia
Nov 12 '18 at 21:19
The thing that perplexes me is that the only two locations in which there is a try/catch in the entire process is on the
webservice method
and on the root method
. Does this mean that because there is a second catch on the root method, that this "handles" the webservice exception thus logging both exceptions to NFLogger?– Olivia
Nov 12 '18 at 21:19
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
and if this is the case, then I should take off the exception handling on the webservice method and solely put logging and exception handling on root methods...
– Olivia
Nov 12 '18 at 21:21
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what your
root method
looks like. I assume it is on class A
and is the entry point for the transaction. Does it call NFLogger.logError()
and then not throw anything? That seems like the likely scenario here.– Daniel Ballinger
Nov 12 '18 at 21:34
If in doubt, check the Apex debug log. With an appropriate Apex Code logging level it will show you the flow of execution, including how the exceptions are being handled. I don't know what your
root method
looks like. I assume it is on class A
and is the entry point for the transaction. Does it call NFLogger.logError()
and then not throw anything? That seems like the likely scenario here.– Daniel Ballinger
Nov 12 '18 at 21:34
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception in
postTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.– Daniel Ballinger
Nov 12 '18 at 21:35
How you handle the exceptions is up to you. Generally, it probably wouldn't make sense to log the same exception twice. Also, rethrowing the exception in
postTokenizer
means the call stack trace changes, which will make it harder to debug the actual cause.– Daniel Ballinger
Nov 12 '18 at 21:35
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239103%2fexceptions-and-dml%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does it use
Platform Events
?– Adrian Larson♦
Nov 12 '18 at 20:15
How does
NFLogger
work? It could be using platform events to get outside of the transaction to avoid the rollback. Or if a higher class in the callstack is catching the exception the transaction won't be rolled back.– Daniel Ballinger
Nov 12 '18 at 20:15
@AdrianLarson no platform events. I will update the post with the NFLogger class
– Olivia
Nov 12 '18 at 20:20