4 ms·

But the problem is that checked exceptions create the same “what color is your function” problem for errors.

by dfee 5y ago

simion314 5y ago
>But the problem is that checked exceptions create the same “what color is your function” problem for errors. Compared to "SEGFAULT at 0x000000 in some xxx.dll" having to handle exception and having readable stack traces is a productivity win.
vips7L 5y ago
No one really uses checked exceptions. But I agree they suck, IOException is the bane of my existence. It's the #1 reason why I don't like Rust or Go. Checking errors is dreadful.
- pkolaczk 5y ago
  > Checking errors is dreadful. That's true, but that doesn't mean we should pretend the problem does not exist. Using unchecked exceptions is sweeping things under the carpet. Generally unchecked exceptions should be used only for bugs (array index out of bounds) or unrecoverable situations (JVM crash, no memory). I/O does not belong there.
pkolaczk 5y ago
That's not the real problem with checked exceptions in Java. You actually have the same problem with any result type in a language with static types and mandatory explicit types in function signatures - you change one type and you have to adjust the callers, sometimes many levels above. This is just life ;) One of biggest troubles with checked exceptions is that in Java it is impossible to generify them the same way you can do with argument and return types. You can't write a generic filter or map function that throws the same checked exceptions as the lambda (or any other interface object) that gets passed as an argument. This makes it impossible to use code that throws checked exceptions in some contexts and forces developers to wrap them in RuntimeException. And because those situations are extremely common these days, especially after some FP techniques influenced how Java code is being written, almost noone uses checked exceptions and you typically get runtime exceptions flying around the whole codebase. Which are even worse - they turn very quickly into an unmaintainable mess - because now any function can throw just anything at any time, and that's not even explicitly visible. And here we get to the next big problem with exceptions (not just checked exceptions): they add a high number of alternative control flows you need to analyze in addition to the main "happy path" of the program. An exception can happen anywhere and it might leave the data in incorrect, partially updated state. In reality many devs simply pretend the problem doesn't exist, and they check the happy path only. In languages with no exceptions, a function can exit only by an explicit return - and that is way more readable and easier to analyze. And the last thing which seems to be more a cultural problem, rather than a Java problem, is that somehow most Java programs communicate typical, expected problems with ugly and mostly useless exception stacktraces. Can't connect to a host? I get a stacktrace. File not found? Two screens of stacktraces... That's IMHO a terrible approach to error handling. As a user I am totally uninterested in what code was being executed when something failed (that should be reported only for bugs so the developers can fix). I'm interested in getting a human-readable message with context helping me understand what went wrong and how to fix it.
sabageti 5y ago
It isn't? You have a function red that doesn't throws anything you use a function blue that throws checked exceptions you handle the exception and it's all. The red functions doesn't become blue.
- dfee 5y ago
  if the "red" function isn't successful, than you're mapping that error to what? a RuntimeException? great – you've now escaped the indirection with the original solution – just use RuntimeExceptions. map it to another checked exception and you now have a "blue" function. and, you also have another layer of abstraction in your errors. if you can't actually handle the error, skip the circus and just let the exception propagate to a general error boundary (alongside all those RuntimeExceptions you're unaware of). It's a deep ocean, your defense mechanism of guarding against Checked Exceptions is a small fraction of all exceptions. To be fair, I did really like the idea of checked functions when I first started using Java. But in practice, it's just too hard to tell what operations should be Checked / Unchecked (sometimes).

But the problem is that checked exceptions create the same “what color is your function” problem for errors.

by dfee 5y ago

But the problem is that checked exceptions create the same “what color is your function” problem for errors.

>But the problem is that checked exceptions create the same “what color is your function” problem for errors. Compared to "SEGFAULT at 0x000000 in some xxx.dll" having to handle exception and having readable stack traces is a productivity win.

vips7L 5y ago

No one really uses checked exceptions. But I agree they suck, IOException is the bane of my existence. It's the #1 reason why I don't like Rust or Go. Checking errors is dreadful.

pkolaczk 5y ago
> Checking errors is dreadful. That's true, but that doesn't mean we should pretend the problem does not exist. Using unchecked exceptions is sweeping things under the carpet. Generally unchecked exceptions should be used only for bugs (array index out of bounds) or unrecoverable situations (JVM crash, no memory). I/O does not belong there.

pkolaczk 5y ago

That's not the real problem with checked exceptions in Java. You actually have the same problem with any result type in a language with static types and mandatory explicit types in function signatures - you change one type and you have to adjust the callers, sometimes many levels above. This is just life ;) One of biggest troubles with checked exceptions is that in Java it is impossible to generify them the same way you can do with argument and return types. You can't write a generic filter or map function that throws the same checked exceptions as the lambda (or any other interface object) that gets passed as an argument. This makes it impossible to use code that throws checked exceptions in some contexts and forces developers to wrap them in RuntimeException. And because those situations are extremely common these days, especially after some FP techniques influenced how Java code is being written, almost noone uses checked exceptions and you typically get runtime exceptions flying around the whole codebase. Which are even worse - they turn very quickly into an unmaintainable mess - because now any function can throw just anything at any time, and that's not even explicitly visible. And here we get to the next big problem with exceptions (not just checked exceptions): they add a high number of alternative control flows you need to analyze in addition to the main "happy path" of the program. An exception can happen anywhere and it might leave the data in incorrect, partially updated state. In reality many devs simply pretend the problem doesn't exist, and they check the happy path only. In languages with no exceptions, a function can exit only by an explicit return - and that is way more readable and easier to analyze. And the last thing which seems to be more a cultural problem, rather than a Java problem, is that somehow most Java programs communicate typical, expected problems with ugly and mostly useless exception stacktraces. Can't connect to a host? I get a stacktrace. File not found? Two screens of stacktraces... That's IMHO a terrible approach to error handling. As a user I am totally uninterested in what code was being executed when something failed (that should be reported only for bugs so the developers can fix). I'm interested in getting a human-readable message with context helping me understand what went wrong and how to fix it.

sabageti 5y ago

It isn't? You have a function red that doesn't throws anything you use a function blue that throws checked exceptions you handle the exception and it's all. The red functions doesn't become blue.

dfee 5y ago
if the "red" function isn't successful, than you're mapping that error to what? a RuntimeException? great – you've now escaped the indirection with the original solution – just use RuntimeExceptions. map it to another checked exception and you now have a "blue" function. and, you also have another layer of abstraction in your errors. if you can't actually handle the error, skip the circus and just let the exception propagate to a general error boundary (alongside all those RuntimeExceptions you're unaware of). It's a deep ocean, your defense mechanism of guarding against Checked Exceptions is a small fraction of all exceptions. To be fair, I did really like the idea of checked functions when I first started using Java. But in practice, it's just too hard to tell what operations should be Checked / Unchecked (sometimes).