If an exception is caught on the application layer that differs from the one where it has been thrown, and it SHOULD be re-thrown, you SHOULD create a new exception instance that is appropriate for the current layer. It is allowed to throw exceptions that are only defined on the same layer.ĥ.12. A separate exceptions hierarchy SHOULD be defined on each application layer. \Exception SHOULD NOT be thrown in Front Controller and Action Controllers.ĥ.11.
Dev docs magento code#
\Exception SHOULD be caught only in the code that calls third-party libraries, in addition to catching specific exceptions thrown by the library.ĥ.10. All direct communications with third-party libraries MUST be wrapped with a try/catch statement.ĥ.9.
The top generic \Exception SHOULD NOT be thrown anywhere.ĥ.8. Thrown exceptions SHOULD be as specific as possible. The short name of an exception class MUST be clear, meaningful, and state the cause of exception.ĥ.7. Conditional statements SHOULD be used instead.ĥ.6. Business logic (both application and domain) MUST NOT be managed with exceptions.
Dev docs magento how to#
It is the processing code that decides how to process an exception.ĥ.5. Exceptions MUST NOT handle message output. If a function A calls function B, and function B might throw an exception, this exception MUST be either processed by function A or declared by the annotation in the documentation block of function A.ĥ.4. Exceptions MUST NOT be handled in the same function where they are thrown.ĥ.3. All exceptions that are surfaced to the end user MUST produce error messages in the following format:ĥ.2. Plugins SHOULD NOT change the state of an intercepted object (Intercepted object is $subject). Plugins SHOULD NOT be added to data objects.Ĥ.5. Plugins SHOULD NOT be used within own module.Ĥ.3. Around-plugins SHOULD only be used when behavior of an original method is supposed to be substituted in certain scenarios.Ĥ.2. All modular Presentation layer DI settings SHOULD be stored in /etc//di.xml. All modular DI settings (except for Presentation layer configuration) SHOULD be stored in /etc/di.xml.ģ.4. The app/etc/di.xml file MUST contain only framework-level Dependency Injection (DI) settings.ģ.3. There SHOULD be no circular dependencies between objects.ģ.2. Strategy SHOULD be used when there are multiple algorithms for performing an operation.
In this case, you can create a ConfigReaderInterface with a composite implementation - ConfigReaderComposite, and configure particular readers as children of a composite reader.Ģ.17.3. You need to read configuration from different sources (like database or filesystem) and want to make the reading process configurable: allow extensions to add more configuration sources. No additional public initialization methods are allowed.
An object MUST be ready for use after instantiation. Object decomposition MUST follow the SOLID principles.Ģ.2.1. PHP interfaces MAY have this declaration. All updated PHP files SHOULD have strict type mode enabled. All new PHP files MUST have strict type mode enabled by starting with declare(strict_types=1). Type hints for scalar arguments SHOULD be used.ġ.3.1. Explicit return types MUST BE declared on functions.ġ.3. Function arguments SHOULD NOT be modified.ġ.2. We strongly believe that new technical initiatives should follow these recommendations, and the existing code should be improved to meet them. These guidelines came from many years of hard work, experience, and discussions.
Magento core developers use this document as a reference during code reviews some rules have corresponding code checks in the Magento static tests. This document lists the fundamental coding and application design principles that guide Magento 2 developer team members.
0 kommentar(er)
