> Most of my code is error checking and handling.

> Plenty of noob code ignores errors.

You can encode errors into the return type of the function to force people to deal with errors. Here's a good example:

  byte[] read() throws IOException
    // vs
  Optional<byte[]> read()

Both cases force the user to consider failure cases.

Checked exceptions are essentially modifying the return type already, just in a different syntax. It's inconvenient because the nonstandard syntax for the type doesn't work well with all the other return types. It's still a bit inconvenient to use the other option in Java though because there's no language level support for real tagged unions (sum type) (union type). https://en.wikipedia.org/wiki/Tagged_union

The other class of not handling errors takes a bigger conceptual leap:

  void write(byte[]) throws IOException
    // vs
  Optional<Void> write(byte[])

The caller could just ignore the value in Java, so your criticism is still valid. However, you can force the caller to never implicitly ignore return values. If the function 'throws' by returning a value, you have to explicitly ignore it:

  val _ = write(bytes);

If the function can't throw (i.e. the return type is strictly 'void'), then you don't have to do anything:

  write(bytes);

> Why would network programming (I/O, persistence, etc) look any different whether the language was C, Java, GoLang or other?

Because different languages provide different abstractive tooling and can thus yield different solutions?

> Plenty of noob code ignores errors. I sort of thought we all decided that was suboptimal. Java's response was checked exceptions.

And it was a bad one. Which is OK, everybody makes mistakes. That doesn't change the fact that Java's checked exceptions are bad.

> The only argument I've ever heard that made any sense is the silliness of catching exceptions so far removed from the root cause that your code can't do anything about it.

Made any sense with respect to what? Checked exceptions? They're bad because their classification is often incorrect (exceptions are checked which should not have been, mainly IOException) and Java provides no abstractive capabilities over them so you can't build tooling around them or intermediate layers which are not aware of the specific checked exceptions without losing that specificity (you can't be polymorphic over checked exception), they're either extremely leaky or completely erased, and things have gotten worse as Java integrated more functional features which have run head-first into these issues.

Plus they're inconvenient, because managing exceptions in Java is as verbose as everything else and by definition checked exceptions requires more management than unchecked.

> It now occurs to me that the checked exception abolitionists are advocating Happy Path Programming.

That's certainly not correct. Checked exceptions "abolitionists" just consider Java's checked exceptions to be bad.