when the stack trace wasn't included in the error logging

fuck me, how the fuck am i supposed to know where the exception occurred

perhaps i've taken it all for granted thinking that the default toString implementation of an exception would've included that

Yes, that was a wrong assumption

And when you have the stack trace and it leads you this piece of code.

The underlying OCR validation processes dozens of decimal property values, so it's anyone's guess which property and what the value is. Is it 'Foo'? Is it '$0.00abc123'?

When asked about at least including what the value is in the exception.

M: "We get maybe 4 or 5 of those errors an hour, not enough to care about. Probably bad data anyway."

My inner child is screaming "WHY DON'T YOU WANT TO KNOW?!!!!"

At a minimum, you'll *know* it's bad data from the OCR instead of assuming+ignoring.

@PaperTrail I'm confused as to why someone thought there's no need to log the value that cannot be parsed, but also created a parameter whose only purpose seems to be printed in the error message. Plus using a basic Exception class here doesn't seem like a great idea, if you want to handle this cleanly..

But I'm too low on context here to roast this piece of code properly.

@saucyatom > "But I'm too low on context here to roast this piece of code properly"

You pretty much nailed how a lot of devs handle exceptions. Does it matter? In the big picture, probably not. I find it frustrating they don't even try.

@PaperTrail > "In the big picture, probably not."

*UPDATE*

I added the value to the exception, logged, turned out the bad value was a date. Not caring about where the bad data was coming from, I handed off that journey to the original dev.

Dev: "Found it, my mistake. I was passing the invoice date instead of the amount. Fixed."