Comment by Tcepsa
3 days ago
In the reserved case you do still need to check if you have a reserved entity, but you can put it (along with the other allowed "pseudotypes") in a switch/case block and have it just break back out immediately (the no-op mentioned in the article) rather than having to use a separate if/else to check for Null, or clutter things up with a try/catch wrapper.
Does that address what you're asking about?
But that assumes I have some switch case somewhere right? If I passed an array of "orders" to a downstream function, it knows that what it has is orders, not something else, so it doesn't need to check for anything, and in the case I checked for errors upstream (when I try to allocate a new order) all downstream functions know that no invalid order can be passed, in which case you only have one check at creation time.
That's why I haven't fully understood yet how working like this is simpler.
Fair enough; in the example provided the "tag" was allowed to be "bid, ask, or reserved" so I assumed there would be a switch statement to control the handling of the bid and ask specifics, and that it could drop the reserved ones there. That's less helpful when it's just between "is this an actual instance or just a placeholder?"
Why is a try/catch wrapper clutter but a switch case is not?
I had assumed that there would already be a switch/case because I was going with the example in the code of there being three pseudotypes (bid, ask, and reserved). So it seemed natural to me to use a switch statement to have it execute the code specific to them, and that doing so would be less cluttered than not having the reserved option and instead doing a switch/case (or if/else-if) for bid/ask and a separate try/catch wrapper in case it was a null object.
Edit: to be clear, I agree that the distinction is not nearly as sharp if it's just a case of "is the object valid or not"