

Why we avoid throwing exceptions at StackMob - zazenergy
https://blog.stackmob.com/2013/03/why-we-avoid-throwing-exceptions-at-stackmob/

======
tempaccount9473
So they have created an mechanism that allows replacing a small subset of what
execptions can do (communicate errors to the callers of a function).

The downside is they need to write all code in a non-standard idiom, need
wrappers around standard libraries, cannot easily bubble up errors through
multiple levels of the callstack when appropriate, and have made their typing
system significantly more complex.

I cannot see an upside.

The example they gave, that division by zero is a "crafty little exception can
sneak out of our net and crash our program", could just have easily been
solved by wrapping division in a try/except block that caught the
RuntimeException, and threw a MyDivisionByZero exception. Then the compiler
would enforce that the exception must be caught, elimiating their handwaving
argument that unchecked runtime exceptions are "the wild west".

------
jfabre
\- "Number 3 is the problematic one. If the exceptions are unchecked we’re in
the wild west again."

Hum, I'm going to argument at the same level: Wat?

------
btipling
Exceptions are idiomatic, widely supported and immediately available. The
convoluted alternative presented here is not. I have never seen inherent
problems with exceptions. Another "exceptions are exceptional claim" without
any convincing evidence.

~~~
devmage
"idiomatic, widely supported and immediately available"

So is McDonalds, but that doesn't necessarily make it good for you. What Doug
is getting at in his post is that there are cleaner and more interesting (and
often more useful) ways to deal with exceptions, apart from writing out
incessant try-catch-finally blocks.

disclaimer: I work with Doug

