[The_Colonel]

> They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.

Syntactic sugar it needs is an easy way (like ! prefix) to turn it to a runtime exception.

Procrastinating on exceptions is usually the correct thing to do in your typical business application - crash the current business transaction, log the error, return error response. Not much else to do.

Instead the applications are now littered with layers of try-catch-rethrow (optionally with redundant logging and wrapping into other useless exceptions) which add no benefit.

[jeroenhd]

The try/catch/rethrow model can easily be substituted by just adding a `throws` to the method. If you truly don't care, just make your method `throws Exception` or even `throws Throwable` and let the automatic bubbling take care of making you handle exceptions at top level.

[The_Colonel]

That (or rather checked exceptions in general) doesn't play well with lambdas / streams.

[pinoy420]

How many errors are actually recoverable. I bet most thrown exceptions could be replaced with a printf(“it went wrong here”) for all their utility.

[bluGill]

I disagree. The real value of exceptions is you can skip 6 levels of functions that have lines like

status = DoThing(); if(status != allIsWell) {return status;}

C++ embedded for a long time has said don't use exceptions they are slow. However recent thinking has changed - turns out in trivial code exceptions are slow but in more real world code exceptions are faster than all those layers if checks - and better yet you won't give up on writing all the if checks. Thus embedded projects are starting turn exceptions on (often optimized exceptions with static pre allocated buffers)

The final "print something when wrong" is of little value, but the unwinding is very valuable.

[ackfoobar]

> The real value of exceptions is you can skip 6 levels of functions that have lines like

For some reason some Go programmers think those lines are the best thing since sliced bread.

[hasley]

Do you have any references for that? I used to avoid exceptions on small Cortex M0/M3 devices as well.

[bluGill]

Khalil Estell has some great work on that. https://www.youtube.com/watch?v=bY2FlayomlE is one link - very low level technical of what is really happening. He has other talks and papers if you search his name.

[hasley]

Nice, thank you!

[The_Colonel]

Well, usually you want to handle it at some level - e.g. a common REST exception handler returning a standard 500 response with some details about what went wrong. Or retry the process (sometimes the errors may be intermittent)