Thinking About Duck Typing And Errors And Events
The other day, I posted about my first exploration of Circuit Breakers in ColdFusion. In that approach, I used a seamless proxy in which the Circuit Breaker exposed the exact same method surface area that the target / origin component exposed. I viewed this as "Duck Typing" and I thought I was being clever, allowing the proxied component and the origin component to be transparently swapped in and out of use. Eventually, however, I realized that this approach was flawed; and, moreover, that I had never really considered errors and emitted events in the context of Duck Typing.
I doubt that I could give you the proper definition of Duck Typing but, the way it's always been explained to me is (and the way I understand it):
| |
|
|
||
| |
 |
|
||
| |
|
|
Meaning, if two objects look and act the same, they can be considered the same "type," even if they are not part of the same Class hierarchy.
In the past, I've only ever thought about this in terms of methods and properties exposed on a given object. But, methods and properties are only part of how the world interacts with an object. Objects may also throw errors and emit events (depending on the type of object). The question then becomes: are throwable errors and emitted events part of the "type" of an object? My gut says yes.
| |
|
|
||
| |
 |
|
||
| |
|
|
In order to catch specific errors and bind to specific events, the calling context must know that those errors and events can originate from said object - they are part of the object definition.
This is part of why my first take on Circuit Breakers was so flawed. The Circuit Breaker "proxy" version of the origin component was capable of throwing a special error - "CircuitBreaker.Open" - as part of its fail-fast workflow. But, the calling context can only react to this error if it knows that the object it has on-hand is a CircuitBreaker proxy; which, of course, means that the CircuitBreaker proxy and the origin component cannot be transparently swapped - they are not the same "type" of object and do not exhibit the same error-behavior.
This is mostly just me thinking out load about Duck Typing and what it means for an object to be of a certain "type". Learning about Angular 2 and TypeScript has also helped me think much more deeply about types as well. Luckily, TypeScript can call you out when you make certain "duck typing" mistakes. But, it won't help you with errors or event type, which I now believe are part of the philosophy of duck typing.
Reader Comments