[tankenmate]

The one item I'd really contend is where it says it "makes it easier to ... maintain over time".

That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, welcome to distributed systems (logically, physically or chronologically distributed)).

[EDIT] fixed thinko

[trinovantes]

This is one of the reasons why I really like monorepos. Tracking down an opaque error from 2 network hops away is a nightmare compared to reading an exception in a call stack

[knz42]

This was clarified in the conf talk [1] [2]: error returns should be used at API boundaries, and panic-driven handling only "within" a component.

[1] https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s

[2] https://docs.google.com/presentation/d/1WVu4O-ax7punUC2V_XgT...

[tankenmate]

For simplicities sake I just use error returns everywhere and then you have a consistent error handling abstraction (and one that scales to boot).

[DoctorNick]

thank you for emulating the experience of debugging distributed systems