Magento 2 using around interceptor/plugin to modify exception message
In the MagentoCheckoutModelPaymentInformationManagement::savePaymentInformationAndPlaceOrder() method all exceptions are caught and CouldNotSaveException is created with a generic message.
I want to make this message user friendly as I am implementing a fairly complex restriction and the generic message would cause lots of confusion for the customer.
public function savePaymentInformationAndPlaceOrder(
$cartId,
MagentoQuoteApiDataPaymentInterface $paymentMethod,
MagentoQuoteApiDataAddressInterface $billingAddress = null
) {
$this->savePaymentInformation($cartId, $paymentMethod, $billingAddress);
try {
$orderId = $this->cartManagement->placeOrder($cartId);
} catch (Exception $e) {
throw new CouldNotSaveException(
__('An error occurred on the server. Please try to place the order again.'),
$e
);
}
return $orderId;
}
My idea to work around this issue was to create an around plugin so that I could catch the new Exception the throw the previous exception which I create via an observer level check.
public function aroundSavePaymentInformationAndPlaceOrder(
MagentoCheckoutModelPaymentInformationManagement $subject,
callable $proceed,
...$args
) {
try {
$result = $proceed(...$args);
} catch (MagentoFrameworkExceptionCouldNotSaveException $e) {
throw $e->getPrevious();
}
return $result;
}
magento2 interceptor
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
add a comment |
In the MagentoCheckoutModelPaymentInformationManagement::savePaymentInformationAndPlaceOrder() method all exceptions are caught and CouldNotSaveException is created with a generic message.
I want to make this message user friendly as I am implementing a fairly complex restriction and the generic message would cause lots of confusion for the customer.
public function savePaymentInformationAndPlaceOrder(
$cartId,
MagentoQuoteApiDataPaymentInterface $paymentMethod,
MagentoQuoteApiDataAddressInterface $billingAddress = null
) {
$this->savePaymentInformation($cartId, $paymentMethod, $billingAddress);
try {
$orderId = $this->cartManagement->placeOrder($cartId);
} catch (Exception $e) {
throw new CouldNotSaveException(
__('An error occurred on the server. Please try to place the order again.'),
$e
);
}
return $orderId;
}
My idea to work around this issue was to create an around plugin so that I could catch the new Exception the throw the previous exception which I create via an observer level check.
public function aroundSavePaymentInformationAndPlaceOrder(
MagentoCheckoutModelPaymentInformationManagement $subject,
callable $proceed,
...$args
) {
try {
$result = $proceed(...$args);
} catch (MagentoFrameworkExceptionCouldNotSaveException $e) {
throw $e->getPrevious();
}
return $result;
}
magento2 interceptor
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51
add a comment |
In the MagentoCheckoutModelPaymentInformationManagement::savePaymentInformationAndPlaceOrder() method all exceptions are caught and CouldNotSaveException is created with a generic message.
I want to make this message user friendly as I am implementing a fairly complex restriction and the generic message would cause lots of confusion for the customer.
public function savePaymentInformationAndPlaceOrder(
$cartId,
MagentoQuoteApiDataPaymentInterface $paymentMethod,
MagentoQuoteApiDataAddressInterface $billingAddress = null
) {
$this->savePaymentInformation($cartId, $paymentMethod, $billingAddress);
try {
$orderId = $this->cartManagement->placeOrder($cartId);
} catch (Exception $e) {
throw new CouldNotSaveException(
__('An error occurred on the server. Please try to place the order again.'),
$e
);
}
return $orderId;
}
My idea to work around this issue was to create an around plugin so that I could catch the new Exception the throw the previous exception which I create via an observer level check.
public function aroundSavePaymentInformationAndPlaceOrder(
MagentoCheckoutModelPaymentInformationManagement $subject,
callable $proceed,
...$args
) {
try {
$result = $proceed(...$args);
} catch (MagentoFrameworkExceptionCouldNotSaveException $e) {
throw $e->getPrevious();
}
return $result;
}
magento2 interceptor
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
In the MagentoCheckoutModelPaymentInformationManagement::savePaymentInformationAndPlaceOrder() method all exceptions are caught and CouldNotSaveException is created with a generic message.
I want to make this message user friendly as I am implementing a fairly complex restriction and the generic message would cause lots of confusion for the customer.
public function savePaymentInformationAndPlaceOrder(
$cartId,
MagentoQuoteApiDataPaymentInterface $paymentMethod,
MagentoQuoteApiDataAddressInterface $billingAddress = null
) {
$this->savePaymentInformation($cartId, $paymentMethod, $billingAddress);
try {
$orderId = $this->cartManagement->placeOrder($cartId);
} catch (Exception $e) {
throw new CouldNotSaveException(
__('An error occurred on the server. Please try to place the order again.'),
$e
);
}
return $orderId;
}
My idea to work around this issue was to create an around plugin so that I could catch the new Exception the throw the previous exception which I create via an observer level check.
public function aroundSavePaymentInformationAndPlaceOrder(
MagentoCheckoutModelPaymentInformationManagement $subject,
callable $proceed,
...$args
) {
try {
$result = $proceed(...$args);
} catch (MagentoFrameworkExceptionCouldNotSaveException $e) {
throw $e->getPrevious();
}
return $result;
}
magento2 interceptor
magento2 interceptor
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
asked Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
526417
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51
add a comment |
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51
add a comment |
1 Answer
1
active
oldest
votes
This does actually work it was just the di.xml wasn't triggering on the if it was defined in etc/frontend/di.xml but was fine in etc/di.xml.
Unsure why but it seems to be a decent way of working around Magento's decision to use a generic exception.
<type name="MagentoCheckoutModelPaymentInformationManagement">
<plugin name="namespaceModulePaymentInformationManagement"
type="NamespaceModulePluginCheckoutModelPaymentInformationManagement"/>
</type>
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "479"
};
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%2fmagento.stackexchange.com%2fquestions%2f157061%2fmagento-2-using-around-interceptor-plugin-to-modify-exception-message%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
This does actually work it was just the di.xml wasn't triggering on the if it was defined in etc/frontend/di.xml but was fine in etc/di.xml.
Unsure why but it seems to be a decent way of working around Magento's decision to use a generic exception.
<type name="MagentoCheckoutModelPaymentInformationManagement">
<plugin name="namespaceModulePaymentInformationManagement"
type="NamespaceModulePluginCheckoutModelPaymentInformationManagement"/>
</type>
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
add a comment |
This does actually work it was just the di.xml wasn't triggering on the if it was defined in etc/frontend/di.xml but was fine in etc/di.xml.
Unsure why but it seems to be a decent way of working around Magento's decision to use a generic exception.
<type name="MagentoCheckoutModelPaymentInformationManagement">
<plugin name="namespaceModulePaymentInformationManagement"
type="NamespaceModulePluginCheckoutModelPaymentInformationManagement"/>
</type>
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
add a comment |
This does actually work it was just the di.xml wasn't triggering on the if it was defined in etc/frontend/di.xml but was fine in etc/di.xml.
Unsure why but it seems to be a decent way of working around Magento's decision to use a generic exception.
<type name="MagentoCheckoutModelPaymentInformationManagement">
<plugin name="namespaceModulePaymentInformationManagement"
type="NamespaceModulePluginCheckoutModelPaymentInformationManagement"/>
</type>
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
This does actually work it was just the di.xml wasn't triggering on the if it was defined in etc/frontend/di.xml but was fine in etc/di.xml.
Unsure why but it seems to be a decent way of working around Magento's decision to use a generic exception.
<type name="MagentoCheckoutModelPaymentInformationManagement">
<plugin name="namespaceModulePaymentInformationManagement"
type="NamespaceModulePluginCheckoutModelPaymentInformationManagement"/>
</type>
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
answered Jan 30 '17 at 14:25
jzahediehjzahedieh
526417
526417
add a comment |
add a comment |
Thanks for contributing an answer to Magento 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.
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%2fmagento.stackexchange.com%2fquestions%2f157061%2fmagento-2-using-around-interceptor-plugin-to-modify-exception-message%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
you should avoid usages of around plugins, they reduce Magento performance. About custom exception message, Magento provides only high-level errors to make an application more secure, if you use error messages from payment methods as is, you should be sure what you don't make your application vulnerable.
– joni jones
Jan 31 '17 at 9:10
@jonijones oh really, do you have any further reading on the performance implications? Regarding the security issue I've created a custom exception and am checking the previous exception is my specific exception before re--throwing it. I was going to include it in the question but thought it might over complicate it.
– jzahedieh
Jan 31 '17 at 11:27
Magento dev docs describe the usage of plugins but do not describe negative aspects. The common issue of around plugins, it's how they implemented in Magento, a chain of around plugins consumes a lot of memory. In Magento 2.2 will be removed most of around plugins in core modules.
– joni jones
Jan 31 '17 at 11:51