A new path for getting
geo::BooleanOps without panics
Last week I stumbled upon yet another case where the
methods panic. This is highly frustrating since it keeps me from using the
code. The reason for this is that I can't let my app crash and I can't even
catch the panics with some fancy shenanigans. After countless attempts to
- a standalone implementation from the ground up (my tip: don't do it. There are infinitly many special cases and you're not smarter than what is already available)
- a safe wrapper around the existing
geo::BooleanOpswhich won't panic
I decided to give one last other idea another try
About one year ago I already tried to just "resultify" all the places where the
current implementation of the operations in the
geo repository can panic.
However, back then we got stuck at one place. At some point in the
implementation we need to get the result through the
next method of the
Iterator trait. Since the method has to return an
Option<Item>, we thought
it would be impossible to make the changes and we gave up. Nowadays I'm a tiny
bit smarter though. Although it is a bit hacky, we can just return a
Option<Result<Item, Error>> and then make use of the
transpose method on
Option<Result<..,..>> types to get the desired information through the trait
method. After some fiddling, I finally came up with a first draft for the new
falliable methods on the old
BooleanOps trait. You can find the draft PR here.
It worked fine for my use case. Let's see how far this will go. It finally feels like we're getting control over the problem.
The tails of broken windows
Excerpt from The Pragmatic Programmer
The following is one of the most powerful ideas I've read about so far.
Entropy is a term which doesn't only exist in the physical world. It's also a real thing in software engineering when it comes to the amount of disorder in code bases. Unfortunately the entropy in informatics behaves the same way as in physics, it tends to increase over time. Sometimes we also call it technical debt. Let's take a look at a small comparison that will help us to understand how to tame that phenomenon.
In most inner cities there are two kinds of buildings. Some are beautiful and clean while others seem to rot over time. The question is: why is that? Researchers in the field of crime and urban decay stumbled across an interesting trigger, that can turn a beautiful neighborhood into a abandoned place over time.
It's a broken window.
One broken window, left for any substantial length of time, can instill a sense of abandonment in it's inhabitants. It raises a feeling that other residents who are responsible just don't care about the livelihood which decreases motivation to do the simplest maintanence. So after some time another window gets broken, people start littering, amateur graffiti appears everywhere and serious structural damage starts to manifest. When it gets to this point, the damages reach a point where it isn't even desireable for the owner of the house to fix it at all and the decay continues until the building is a complete ruin.
Why is that? Psychologists have done studies that show that hopelessness can be contagious. Ignoring a clearly broken situation reinforces the idea that perhaps nothing can be fixed, that noone cases and everything is doomed. All these negative thoughts can spread amongst team members creating a vicious spiral. So the one important conclusion from that story is:
Don't live with broken windows
Don't leave "broken windows" (bad designs, wrong decisions, poor code) unrepaired. Fix each one as soon as it is discovered and if there is insufficient time to fix it, at least create a plan and save that somewhere for later. Perhaps you can also just comment out the offending code, or display a "Not implemented" message, or substitute dummy code instead. Take some kind of action now to show you're on top of the situation, that someone cares and to prevent further damage.
Just always remind yourself: "No broken windows".