Handling Exceptions Nobody Asked For

Description

A multi-panel comic strip depicting a knight in full armor standing over a slain dragon, yelling up to a princess in a tower. The dialogue shows the knight proudly announcing he's 'handled the dragon exception' to rescue her. The princess, however, retorts that she didn't need rescuing and never asked him to kill the dragon. The humor lies in the application of a programming concept - exception handling - to a fantasy scenario. It satirizes the common developer anti-pattern of over-engineering or proactively solving a problem that the end-user (the 'princess') is either unaware of or doesn't consider a problem, leading to a solution that is technically implemented but functionally unwanted

Common Tags

CodingHumor ErrorHandling ExceptionHandling DeveloperHumor TechMeme ProductionIncidents

Comments

Anonymous ★ Top Pick That's not a handled exception, that's a memory leak in the requirements gathering phase that resulted in you creating a daemon process nobody can kill

Anonymous ★ Top Pick

That's not a handled exception, that's a memory leak in the requirements gathering phase that resulted in you creating a daemon process nobody can kill
Anonymous

Current resilience strategy: try { criticalPath(); } catch(Exception ignored) { prometheusCounter.success++; return 200; } - turns real fires into green dashboards and my pager into Schrödinger’s smoke alarm
Anonymous

After 20 years in the industry, I've learned that the most dangerous code isn't the complex distributed system or the clever bit manipulation - it's the junior's first PR with 47 empty catch blocks, each one a tiny time bomb waiting to turn your 3am on-call into a forensic archaeology expedition through logs that just say 'Something went wrong.'
Anonymous

The classic 'Pokemon exception handling' - gotta catch 'em all, but never actually deal with them. It's the architectural equivalent of putting duct tape over your check engine light: the dashboard looks clean, but your production environment is still on fire. Senior engineers know that an empty catch block is just technical debt with better PR - you're not handling the error, you're just making it someone else's 3 AM problem
Anonymous

Catch-all exceptions: because propagating that NPE up the callstack would just be rude to the users
Anonymous

Our resilience strategy: catch(Throwable t) { log.debug('THIS IS FINE'); success_counter++; } - SLOs stay green, the room stays on fire
Anonymous

Our resilience strategy was catch(Exception) { return 200; } - observability called it denial-as-a-service
@RiedleroD 2y

depending on the language, you have to. try{ int number = Integer.parseInt(someStringWithPossiblyANumberInIt); }except NumberFormatException{ System.out.println("string is not an integer"); }
1. @ZgGPuo8dZef58K6hxxGVj3Z2 2y
  
  int GetInt(string prompt) { while(true) { Console.Write(prompt + “>”); Try { return int.Parse(Console.ReadLine()); } catch { Console.WriteLine(“We need a valid number here.”); } } }
  
  @ZgGPuo8dZef58K6hxxGVj3Z2 2y
  
  If you want to have exit/cancel then you can use different catches and let the ExitRequestedException through. And wherever you have the beginning of a subroutine you should exit it should leave it and continue by whereever you are supposed to
@RiedleroD 2y

lol my condolences
@dsmagikswsa 2y

I prefer Golang way to wrap the error in the result rather than try catch pattern….especially in Java
@estevanbs 2y

Either pattern is really good too
@Araalith 2y

What about log, retry, rollback or just return null instead?
@Araalith 2y

JS supports exceptions so they can be used for flow-control. Also there are some similar mechanics like retry - finalize (rxjs) or then-catch-finally for Promise.
@biskwiq 2y

inform the user about the error?
@biskwiq 2y

an app can still work after errors. it's not always 5xx, it can be 4xx.