4 ms·

> That bug should have been caught by tests, code reviews and good communication. There's a reason we have compile-time checks. If you think compile-time check

> That bug should have been caught by tests, code reviews and good communication. There's a reason we have compile-time checks. If you think compile-time checks should be replaced with additional tests, code reviews and good communication, then you want a scripting language, not a compiled language. You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer.

insanitybit 3y ago
> unless you are a really bad Java programmer. Here's the thing. You've just described the vast majority of programmers - bad. They're really fucking bad. And language constructs that lead to bad programmers doing stupid things are, unfortunately making things worse for everyone.
erik_seaberg 3y ago
stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.
- chii 3y ago
  or you start doing monads instead, where p operates on a monad (aka, the Optional type). Unfortunately, this ends up propagating out and your entire code base needs to also do this. Tho i reckon it will make your code better in the future, for a short term/temporary pain converting/adding breaking changes etc.
  - erik_seaberg 3y ago
    Yeah, switching to Scala or Kotlin would be the shortest path to do that.
- masklinn 3y ago
  You could also alter the langage woth for exceptions transparency (swift has something like that with “rethrows“). I don’t think that’s close to sufficient to making checked exceptions work tho, let alone good.
pestatije 3y ago
i do...if i ever get an IOException all i have to do is end the app, no need to deal with it in any way different than an unchecked exception https://phauer.com/2015/checked-exceptions-are-evil/ https://phauer.com/2015/checked-exceptions-are-evil/
- breadwinner 3y ago
  Check the root message of this thread... if you use unchecked exceptions you either crash or you swallow all exceptions. Both are evil, and checked exceptions are the solution.
  - colanderman 3y ago
    That's only possible if your code is 100% correct. Sometimes, your logic is flawed. A condition occurs which you erroneously deduced not to be possible. Unchecked exceptions are the necessary manifestation of these unforeseen errors. Catching them is pointless, what will you do with them? Dynamically fix the logic of your program? What can be the reasonable response to "index out of bounds", try a different index? [1] Depending on the domain it may be appropriate to convert them indiscriminately to checked exceptions at module boundaries (e.g. requests within a server) -- but within said module it remains pointless to catch them. (This is a form of swallowing.) In other domains, crashing is the correct behavior. The code cannot proceed correctly, it must abort. Checked exceptions are appropriate only when the exception can be anticipated and thus planned for, ideally by code closest to where it is thrown. [1] Actually there was a paper a long time ago that monkey-patching C code to return fake "null" data in response to out-of-bounds memory accesses actually resulted in the intended (i.e. correct) behavior in the majority of cases. But I digress.
    - breadwinner 3y ago
      Some errors are recoverable, some are not. When recoverable errors are possible you want to know what those errors are. If you don't then you will crash when you could have recovered. And that's the reason for writing down the list of possible exceptions where recovery and retry are possible (aka checked exceptions). When recovery should not be attempted (example: "index out of bounds") then you don't want to declare or catch the exception, and that's when you use a subclass of RuntimeException in Java.
colanderman 3y ago
> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. (Catching it is wrong -- what would you do to correct something which you believe not to be possible? Forcing the caller to handle it is wrong -- if you don't know what to do with it, they sure won't!) Wrapping checked as unchecked encodes your belief that should it occur, it is a logic error, akin to out-of-bounds array access or null pointer dereference. (Of course, swallowing expected exceptions one is simply too lazy to do anything about is poor practice! Not disagreeing with that.)
- rixed 3y ago
  > if you don't know what to do with it, they sure won't! Actually no. For instance, the caller at some point up the stack may know if something is worth retrying.
  - colanderman 3y ago
    Then you should unwind your state correctly and rethrow as a checked exception stating as much. If there levels up the stack I see a random unexpected "IO Exception" from your library I have no idea whether you are still in a valid state to retry. If I instead see a "Foolib Request Aborted: reason IO Exception" I know you've written logic to handle that case, and I know that retrying is appropriate.
- Hermel 3y ago
  > I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. If it is not possible to occur, then it should not be part of the API. The only time I rethrow a checked exception as an unchecked exception is when the code is still under construction. The default of the eclipse code generator is to log and ignore caught transaction. I think wrapping into an unchecked one is the better default behavior for incomplete code under a "fail fast" policy.
  - colejohnson66 3y ago
hinkley 3y ago
I've given a lot of time and benefit of the doubt to 'testing replaces static analysis' and not only do I know this is not true, but I'm also pretty sure that testing is fundamentally broken. It can't fix anything because it can't even fix itself. Maybe a new testing paradigm will fix it, I certainly keep an eye out for them, but nothing so far. Property based testing is better, but mostly it just reminds me that we had Design By Contract 30 years ago.
sobellian 3y ago
If this were 100% true, everyone would want a language for formal verification (Idris, Coq, etc). Short of those lofty heights we can quibble over the varying strictness of Haskell vs Java vs C and so on.
- edejong 3y ago
  A good programmer knows the limits of the type system. They lean on that knowledge to determine which tests to write.
smrtinsert 3y ago
> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. That's not a given. It's perfectly fine to handle a checked exception via some custom runtime. The nice part is your your code base was given a chance to handle the key exceptions of this particular api all from your ide without you having to refer to documentation etc.

insanitybit 3y ago

> unless you are a really bad Java programmer. Here's the thing. You've just described the vast majority of programmers - bad. They're really fucking bad. And language constructs that lead to bad programmers doing stupid things are, unfortunately making things worse for everyone.

erik_seaberg 3y ago

stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.

chii 3y ago
or you start doing monads instead, where p operates on a monad (aka, the Optional type). Unfortunately, this ends up propagating out and your entire code base needs to also do this. Tho i reckon it will make your code better in the future, for a short term/temporary pain converting/adding breaking changes etc.
- erik_seaberg 3y ago
  Yeah, switching to Scala or Kotlin would be the shortest path to do that.
masklinn 3y ago
You could also alter the langage woth for exceptions transparency (swift has something like that with “rethrows“). I don’t think that’s close to sufficient to making checked exceptions work tho, let alone good.

pestatije 3y ago

i do...if i ever get an IOException all i have to do is end the app, no need to deal with it in any way different than an unchecked exception https://phauer.com/2015/checked-exceptions-are-evil/ https://phauer.com/2015/checked-exceptions-are-evil/

breadwinner 3y ago
Check the root message of this thread... if you use unchecked exceptions you either crash or you swallow all exceptions. Both are evil, and checked exceptions are the solution.
- colanderman 3y ago
  That's only possible if your code is 100% correct. Sometimes, your logic is flawed. A condition occurs which you erroneously deduced not to be possible. Unchecked exceptions are the necessary manifestation of these unforeseen errors. Catching them is pointless, what will you do with them? Dynamically fix the logic of your program? What can be the reasonable response to "index out of bounds", try a different index? [1] Depending on the domain it may be appropriate to convert them indiscriminately to checked exceptions at module boundaries (e.g. requests within a server) -- but within said module it remains pointless to catch them. (This is a form of swallowing.) In other domains, crashing is the correct behavior. The code cannot proceed correctly, it must abort. Checked exceptions are appropriate only when the exception can be anticipated and thus planned for, ideally by code closest to where it is thrown. [1] Actually there was a paper a long time ago that monkey-patching C code to return fake "null" data in response to out-of-bounds memory accesses actually resulted in the intended (i.e. correct) behavior in the majority of cases. But I digress.
  - breadwinner 3y ago
    Some errors are recoverable, some are not. When recoverable errors are possible you want to know what those errors are. If you don't then you will crash when you could have recovered. And that's the reason for writing down the list of possible exceptions where recovery and retry are possible (aka checked exceptions). When recovery should not be attempted (example: "index out of bounds") then you don't want to declare or catch the exception, and that's when you use a subclass of RuntimeException in Java.

colanderman 3y ago

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. (Catching it is wrong -- what would you do to correct something which you believe not to be possible? Forcing the caller to handle it is wrong -- if you don't know what to do with it, they sure won't!) Wrapping checked as unchecked encodes your belief that should it occur, it is a logic error, akin to out-of-bounds array access or null pointer dereference. (Of course, swallowing expected exceptions one is simply too lazy to do anything about is poor practice! Not disagreeing with that.)

rixed 3y ago
> if you don't know what to do with it, they sure won't! Actually no. For instance, the caller at some point up the stack may know if something is worth retrying.
- colanderman 3y ago
  Then you should unwind your state correctly and rethrow as a checked exception stating as much. If there levels up the stack I see a random unexpected "IO Exception" from your library I have no idea whether you are still in a valid state to retry. If I instead see a "Foolib Request Aborted: reason IO Exception" I know you've written logic to handle that case, and I know that retrying is appropriate.
Hermel 3y ago
> I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. If it is not possible to occur, then it should not be part of the API. The only time I rethrow a checked exception as an unchecked exception is when the code is still under construction. The default of the eclipse code generator is to log and ignore caught transaction. I think wrapping into an unchecked one is the better default behavior for incomplete code under a "fail fast" policy.
- colejohnson66 3y ago

hinkley 3y ago

I've given a lot of time and benefit of the doubt to 'testing replaces static analysis' and not only do I know this is not true, but I'm also pretty sure that testing is fundamentally broken. It can't fix anything because it can't even fix itself. Maybe a new testing paradigm will fix it, I certainly keep an eye out for them, but nothing so far. Property based testing is better, but mostly it just reminds me that we had Design By Contract 30 years ago.

sobellian 3y ago

If this were 100% true, everyone would want a language for formal verification (Idris, Coq, etc). Short of those lofty heights we can quibble over the varying strictness of Haskell vs Java vs C and so on.

edejong 3y ago
A good programmer knows the limits of the type system. They lean on that knowledge to determine which tests to write.

smrtinsert 3y ago

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. That's not a given. It's perfectly fine to handle a checked exception via some custom runtime. The nice part is your your code base was given a chance to handle the key exceptions of this particular api all from your ide without you having to refer to documentation etc.