3 ms·

Thank you for replying. It helps me to better articulate my thinking. You're my Rubber Duck. Why would network programming (I/O, persistence, etc) look any dif

Thank you for replying. It helps me to better articulate my thinking. You're my Rubber Duck. Why would network programming (I/O, persistence, etc) look any different whether the language was C, Java, GoLang or other? Most of my code is error checking and handling. (And now logging too, which I'll ignore here.) Is this abnormal? (Being rhetorical.) Plenty of noob code ignores errors. I sort of thought we all decided that was suboptimal. Java's response was checked exceptions. 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. So don't do that. Really, why would any one design a system that way? Because network programming is messy? Because it'd be neat to compartmentalize the messiness? I've been able to cleanly separate the value add business logic from real world messiness exactly one time. I was in control of the full stack, end to end. Imagine something like a useful BizTalk. I had been inspired by postfix. My engine would pass work to plugins, which didn't have to do any I/O of their own. My work anticipated serverless and AWS Lambda, if those programming frameworks (paradigms) were better designed. It now occurs to me that the checked exception abolitionists are advocating Happy Path Programming. The only other feasible Happy Path Programming strategy I know of is Erlang. I've only done an Erlang tutorial, nothing in prod, so this is just a guess.

masklinn 6y ago
> 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.
- hota_mazi 6y ago
  > That doesn't change the fact that Java's checked exceptions are bad You keep saying that but without justifying it. Let's start from the beginning: what is bad exactly, and why: - Checked exceptions in general - Java's implementation of checked exceptions - Or the way some Java API's use checked exceptions ?
  - masklinn 6y ago
    > what is bad exactly The phrase you quoted says exactly what. > and why The next paragraph I wrote explains why.
rovolo 6y ago
> 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 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);
- jayd16 6y ago
  Optional<T> isn't a replacement for typed exceptions as you can't pass or inspect the error details.
  - rovolo 6y ago
    That's correct. I used Optional because it's included in Java and it's simpler. With Optional I could explain handling the presence of errors, but not the inspection of errors. A full replacement is the Result type (a specialized 'Either'): https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/
    - jayd16 6y ago
      Yeah. Although, that has an explicit error type which is good and bad. The errors are consistent and known but you're restricted to throwing them together into a single type. I kind of like C#'s Task type where you can still use the catch block pattern matching if you want to. Maybe dropping the catch syntax is better though.

masklinn 6y ago

> 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.

hota_mazi 6y ago
> That doesn't change the fact that Java's checked exceptions are bad You keep saying that but without justifying it. Let's start from the beginning: what is bad exactly, and why: - Checked exceptions in general - Java's implementation of checked exceptions - Or the way some Java API's use checked exceptions ?
- masklinn 6y ago
  > what is bad exactly The phrase you quoted says exactly what. > and why The next paragraph I wrote explains why.

rovolo 6y ago

> 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 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);

jayd16 6y ago
Optional<T> isn't a replacement for typed exceptions as you can't pass or inspect the error details.
- rovolo 6y ago
  That's correct. I used Optional because it's included in Java and it's simpler. With Optional I could explain handling the presence of errors, but not the inspection of errors. A full replacement is the Result type (a specialized 'Either'): https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/
  - jayd16 6y ago
    Yeah. Although, that has an explicit error type which is good and bad. The errors are consistent and known but you're restricted to throwing them together into a single type. I kind of like C#'s Task type where you can still use the catch block pattern matching if you want to. Maybe dropping the catch syntax is better though.