Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When implementing dependency injection, should exceptions be injected?

My team is muddling through implementing dependency injection in a PHP project using a homebaked DI container. Our first iteration of DI was perhaps taken to the extreme, and even exceptions are being injected into classes that depend on them.

Is this a good practice or overkill?

like image 703
DRock Avatar asked Aug 05 '10 14:08

DRock


People also ask

What does dependency injection require?

Dependency injection is a programming technique that makes a class independent of its dependencies. It achieves that by decoupling the usage of an object from its creation. This helps you to follow SOLID's dependency inversion and single responsibility principles.

When should dependency injection be used?

More specifically, dependency injection is effective in these situations: You need to inject configuration data into one or more components. You need to inject the same dependency into multiple components. You need to inject different implementations of the same dependency.

What is the dependency injection concept?

In object-oriented programming (OOP) software design, dependency injection (DI) is the process of supplying a resource that a given piece of code requires. The required resource, which is often a component of the application itself, is called a dependency.

How does dependency injection work C#?

Dependency Injection is done by supplying the DEPENDENCY through the class's constructor when creating the instance of that class. The injected component can be used anywhere within the class. Recommended to use when the injected dependency, you are using across the class methods.


1 Answers

The purpose of Dependency Injection is to invert the responsibility of obtaining dependencies which are the collaborators used by an object to facilitate configuration or collaborative behavior.

In general, exceptions are inherent to the contract of a given class. That is to say, exceptions are part of the implicit or explicit contract for how a component behaves in the event of a fault and therefore don't lend themselves to being switched out with derivatives. Events also don't typically have behavior, so abstracting them for the purpose of test isolation isn't particularly valuable either. Furthermore, because events typically only represent a fault state or event, being able to inject derivatives of the exception also isn't particularly valuable since any consumers of the component would need to code against the base exception contract (i.e. any additional properties wouldn't be seen).

There are perhaps a few legitimate reasons you might want to inject an exception, such as with the design of an exception handling component which rethrows exceptions after logging, wrapping, etc., or perhaps where the construction of the exception itself requires external resources to achieve (though that need would itself give me pause), but in general I wouldn't say you should be decoupling how a component reports its fault states from the components themselves.

like image 166
Derek Greer Avatar answered Nov 15 '22 23:11

Derek Greer