Log and seppukku.
Ah the perl approach. Do x or die(“it’s fucked”)
Ah, you must work on our firmware team
Yeah, leave some breadcrumbs so the investigators can find out what happened at the crime scene
ON ERROR RESUME NEXTI just add a global error catcher and call it good.
The best part is there’s already a default error handler! If the program dies, you know there was an error.
Just a lot of if-elses checking random stuff?
Or just code the happy path and let it crash.
(this is actually a real philosophy in the Erlang world and I’m bummed it doesn’t receive wider acceptance)
Elixir and Phoenix make perfect sense for our small team.
I can definitely see a lot of good applications for this way of doing things.
It does seem like I often run across “error handling” code that literally just catches a bunch of different exception types and throws a new exception with the same content from the caught error just reworded, adding literally zero helpful information in the process.
It’s definitely the case that sometimes the exact sort of crash you’d get if you didn’t handle errors is exactly the best sort of exception output the program could do given its particular use case and target audience. Or at least it might be best to let the error be handled much further away in the call stack.
I’ve seen a lot worse where they just gobble the original error and throw a new one with 0 of the original context included making it 100x more difficult to debug.
.expect(“Go fuck yourself.”)
Rust programmers writing library code
Me while doing error handling?
Well shit, all my functions both take and return memory addresses. When one of those blocks of data happen to fail the data sanity check, the function returns either -1, -2, -3, -4.
See, you’ll never get such numbers as proper memory addresses, they’re assigned as blocks, larger than 4 bytes…
So, if one of my functions returns a -1 through -4, that tells me which argument to the function failed the sanity check…
