[Roboprog]

Mostly agree, but I'm sure you must have meant UN-checked exceptions :-)

  if ( somethingICanDoNothingAbout)
      { throw new UncheckedGameOverException( "You're screwed!") }

...

  // top level event/request/message handler, many layers up
  catch ( Throwable e)
      { log.error( "Game over:", e); ... }

(I'm with the Anders/C# camp on this one, as much as I dislike MS otherwise)

[moe]

No, I mean Checked Exceptions. Unchecked Exceptions are the devil and should be abolished.

The inclusion of Unchecked Exceptions is one of the biggest warts on the Java language.

[nickbauman]

Unchecked exceptions are for programmer errors. They are an important part of the language since humans (who write the programs) are error prone. They are unrecoverable by nature. Checked exceptions should only exist in situations where the caller can definitely recover from them. Arguably almost nobody does the latter correctly when choosing checked exceptions and the consensus is, as a result, this is the kind of exception that should have been omitted from the language.

[moe]

Unchecked exceptions are for programmer errors. They are an important part of the language since humans (who write the programs) are error prone.

I should clarify: The wart is that programmers can introduce their own unchecked Exceptions. This should not be allowed since, as you say, unchecked Exceptions only make sense for unrecoverable runtime errors.

Checked exceptions should only exist in situations where the caller can definitely recover from them.

False dichotomy. Unchecked exceptions become part of the callee's method signature, i.e. the contract that the caller must fulfill.

Arguably almost nobody does the latter correctly when choosing checked exceptions

Baseless claim. I see many people using Exceptions correctly and elegantly, for error handling and flow control.

and the consensus is

Opinion != consensus.

[Roboprog]

There are times when Go (et al) style multiple return values would better serve a function than exceptions.

For example, a function to parse a string into a number should return both a number-reference, and a flag of some kind (or maybe just an Option). Crap input should not generate an exception like out-of-memory or an I/O error. Trying to dereference the number w/out checking to see if the string was parseable COULD generate a not-mandatory-to-check exception, though.

I guess there is a certain amount of tension between the idea that functions/methods should document the kind of errors/exceptions they might have, and between the annoyance that is all the crappy do-nothing catch clauses that turn around and re-vomit wrapper exceptions that ultimately land in a "well, it didn't work" log message and punt, rather than really "handling" the original exception in any way, shape or form.