6 ms·

How would eliminating checked exceptions mitigate terrible API design? I've never understood the angst. All the arguments reduce down to mitigating terrible ab

How would eliminating checked exceptions mitigate terrible API design? I've never understood the angst. All the arguments reduce down to mitigating terrible abstractions. The Correct Answer is better APIs. Mostly, that means don't pretend the network fallacies don't exist. Embrace them. Which generally means work closer to the metal. I'll say it another way. The problem is EJB, ORMs, Spring, etc. The obfuscation layers. Someone smarter than me will have to rebut the functional programming points. I'd just use a proper FP language. Multiparadigm programming is a strong second on the list of stuff you shouldn't do. (Metaprogramming is first.)

masklinn 6y ago
> How would eliminating checked exceptions mitigate terrible API design? Any API which has used checked exceptions was made worse by those, because Java's checked exceptions are bad, and their use runs actively against good APIs. So not having them would have made the corresponding APIs less bad (not necessarily good, mind) by definition.
- specialist 6y ago
  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.
  - 6y ago

masklinn 6y ago

> How would eliminating checked exceptions mitigate terrible API design? Any API which has used checked exceptions was made worse by those, because Java's checked exceptions are bad, and their use runs actively against good APIs. So not having them would have made the corresponding APIs less bad (not necessarily good, mind) by definition.

specialist 6y ago
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.
- 6y ago