programming confession:
i don't think i've ever written proper, *good* error handling ever π
I suspect most developers don't get past the equivalent of "ON ERROR DIE SCREAMING" in whatever language they use.
@starbreaker @tcql i'm not entirely sure how many developers get to the level of "i should do anything at all if this operation doesn't do what i want it to".
@tcql oooh I did, once. And it was really useful.
@tcql I think most people just focus on letting it crash securely, i.e., who cares about a null pointer, if you use my shit on the Ariane you are a fool
@tcql 90% of good error handling, as far as I can tell, is just making sure that errors always happen in the right place, and never happen in the wrong place. Tedious, I know.
@tcql non-tedius, correct, flexible. pick two.
@tcql It's programmers like you who made exception-throwing popular π ;) ;) but seriously, being consistent about it is hard! I wrote a structured logging framework which helped me, because it let me log issues as return statements:
return $log->err('no config', $errno, $filename);
(Returns the tuple ("ERROR", "no config", $errno, $filename) after logging it)
@tcql Admittedly that doesn't address the need to check return values every single time, which is the harder part.
But even if the return value isn't checked, errors/warnings get logged, which is better than nothing!
@tcql it's really hard!