20 ms·

Well... I will take the bullet and confess that I do like checked exceptions. When they are not miss|over used they transfer the enough required knowledge what

Well... I will take the bullet and confess that I do like checked exceptions. When they are not miss|over used they transfer the enough required knowledge what is to be handled. You dont need to handle? Transfer to higher levels on stack. That is a great fit in my opinion for applications designed with especially fault tolerance futures and using many external components. Not saying that design of CE is perfect, they might be too broad that doesnt tell you exact handle case, so it will leave you in the dark or in a call chain of a()->b()-c()-d() there might be cases that b and c wouldnt need to have contract in their method signature maybe compiler would decide if exception is orphaned or needs to be handled.

narag 6y ago
I just read the article in diagonal. It doesn't seem to address the reason that I hate the thing: sometimes I don't care about errors at all. Let's say I'm writing a kleenex program to explore some feature. Not nice if you make me feel all kind of boilerplate. Or maybe I just want to defer the error management to a higher level. Again busywork declaring exceptions.
- innocenat 6y ago
  It has been a while since I touch Java, but I thought you could just add `throws Exception` to `main` if you don't care about error?
  - mrkeen 6y ago
    And to every other method too
    - TeMPOraL 6y ago
      If it's exploratory trowaway code then you don't care anyway; if it's meant to last, this forces you to actually deal with failure modes instead of pretending they don't exist.
- winter_squirrel 6y ago
  I don't think a language like Java should be optimized for exploration code, it should be optimized for long lived codebases that want to maintain stability and quality. I'd also disagree that adding a throws to the signature is much boilerplate at all. Especially in the ages of IDE's
  - deleted 6y ago
    [deleted]
- narrator 6y ago
  If you don't care about exceptions just put, try { //your code } catch (Exception e) { throw new RuntimeException(e); } around it and you'll be fine. The thing about Java is that the code lasts for a really long time because when it fails, it does so usually with an exception that points to the problem. When promises hang in NodeJS or memory corruption happens in C, it's much more annoying to track down problems.
  - mumblemumble 6y ago
    You can do that - I do it all the time myself - but I'd stop short of saying, "you'll be fine." That approach has its own downside, which is that it makes life obnoxious if you ever do want to actually handle exceptions. Then you'll have to add extra logic to determine if the exception you've caught is the actual error, or just a wrapper of some type. So your error handling inevitably becomes more error-prone. If you can get your team to commit to a "let it crash" policy, though, then it's pretty doable.
  - koolba 6y ago
    You’ll end up double wrapping your exceptions though so your stack traces get a bit uglier. Better to check if it’s a runtime exception and throw it again without wrapping it. Only wrap if it’s not a runtime exception. Also you should check if the thread was interrupted and, if so, set the interrupt flag again. The worst part of this is having that dance littered throughout all your code.
  - bobthepanda 6y ago
    Lombok has @SneakyThrows which does pretty much this but without the additional wrapping.
  - elFarto 6y ago
    There's also this magic function: private static <T extends Throwable> T sneakyThrow(Throwable ex) throws T { throw (T) ex; } Due to generic type erasure, the entire throw clause gets erased so it looks like this method doesn't throw anything.
  - sedatk 6y ago
- ragnese 6y ago
  Then just wrap them in RuntimeException and rethrow them. I mean, why are you writing a kleenex program in Java? Do you not want to declare a return type for your functions either? Java's checked exceptions are just a way to return multiple types from your methods: a success value and a failure values.
  - narag 6y ago
    Everything about what you, and others, are saying seems incredibly wrong to me. I guess it's a point of view thing. Very different mindsets. So it would be more interesting knowing why, but I'm at a loss here. Why should I wrap simplest code with boilerplate? OK, maybe too late, since I need to write several lines of boilerplate to just say hello world. People argue that it's just a template that wraps the program. OK, but now it's something more fine-grained: every function must be wrapped. The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration. I mean, why are you writing a kleenex program in Java? See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?" Do you not want to declare a return type for your functions either? If there isn't a return value, I don't. Java's checked exceptions are just a way to return multiple types from your methods: a success value and a failure values. Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions?
    - ragnese 6y ago
      > The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration. As you already mentioned, that ship has sailed the second you decided to use Java. Every function already has to be wrapped in `class`, which is obnoxious. > See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?" My point wasn't celebrating boilerplate. It's about having a statically typed language. If it's too much to either add `throws Exception` to your function signature or to write a try {} catch {} block, then it must certainly already be too much to write `class MyClass { void myMethod() }`, no? > If there isn't a return value, I don't. You still have to write `void`, don't you? And checked exceptions are supposed to be something you want to force on callers of your code- like a return value. You don't want to return anything? Then return `void` and don't throw any checked exceptions. > Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions? Because it's part of your API. If you write: `int fooMethod(int input) {...}` Then you are saying "If you call `fooMethod` with an int you will get an int." If you always throw an exception on input == 3, then your API is now lying. You should either return a type that encodes the possibility of not being an int OR throw a (checked) InputWasThreeException, to be honest to your caller. Java is a poor language. Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately.
- tedyoung 6y ago
  I've never heard the term "kleenex program", what does that mean?
  - Someone 6y ago
    You write it, use it once, then throw it away.
  - deleted 6y ago
    [deleted]
- zmmmmm 6y ago
  > let's say I'm writing a kleenex program to explore some feature. Not nice if you make me feel all kind of boilerplate. Use Groovy. Seriously, you can code it up with zero boilerplate, use the REPL, notebooks, etc to get your idea into shape, all with 100% interop with your Java libraries. When you are done, if parts of it should graduate to "real code", you can pretty easily port it over or keep parts of it in Groovy and just take the elements over that need to be Java for robustness, etc. This is actually my standard workflow in development now.

narag 6y ago

I just read the article in diagonal. It doesn't seem to address the reason that I hate the thing: sometimes I don't care about errors at all. Let's say I'm writing a kleenex program to explore some feature. Not nice if you make me feel all kind of boilerplate. Or maybe I just want to defer the error management to a higher level. Again busywork declaring exceptions.

innocenat 6y ago
It has been a while since I touch Java, but I thought you could just add `throws Exception` to `main` if you don't care about error?
- mrkeen 6y ago
  And to every other method too
  - TeMPOraL 6y ago
    If it's exploratory trowaway code then you don't care anyway; if it's meant to last, this forces you to actually deal with failure modes instead of pretending they don't exist.
winter_squirrel 6y ago
I don't think a language like Java should be optimized for exploration code, it should be optimized for long lived codebases that want to maintain stability and quality. I'd also disagree that adding a throws to the signature is much boilerplate at all. Especially in the ages of IDE's
- deleted 6y ago
  [deleted]
narrator 6y ago
If you don't care about exceptions just put, try { //your code } catch (Exception e) { throw new RuntimeException(e); } around it and you'll be fine. The thing about Java is that the code lasts for a really long time because when it fails, it does so usually with an exception that points to the problem. When promises hang in NodeJS or memory corruption happens in C, it's much more annoying to track down problems.
- mumblemumble 6y ago
  You can do that - I do it all the time myself - but I'd stop short of saying, "you'll be fine." That approach has its own downside, which is that it makes life obnoxious if you ever do want to actually handle exceptions. Then you'll have to add extra logic to determine if the exception you've caught is the actual error, or just a wrapper of some type. So your error handling inevitably becomes more error-prone. If you can get your team to commit to a "let it crash" policy, though, then it's pretty doable.
- koolba 6y ago
  You’ll end up double wrapping your exceptions though so your stack traces get a bit uglier. Better to check if it’s a runtime exception and throw it again without wrapping it. Only wrap if it’s not a runtime exception. Also you should check if the thread was interrupted and, if so, set the interrupt flag again. The worst part of this is having that dance littered throughout all your code.
- bobthepanda 6y ago
  Lombok has @SneakyThrows which does pretty much this but without the additional wrapping.
- elFarto 6y ago
  There's also this magic function: private static <T extends Throwable> T sneakyThrow(Throwable ex) throws T { throw (T) ex; } Due to generic type erasure, the entire throw clause gets erased so it looks like this method doesn't throw anything.
- sedatk 6y ago
ragnese 6y ago
Then just wrap them in RuntimeException and rethrow them. I mean, why are you writing a kleenex program in Java? Do you not want to declare a return type for your functions either? Java's checked exceptions are just a way to return multiple types from your methods: a success value and a failure values.
- narag 6y ago
  Everything about what you, and others, are saying seems incredibly wrong to me. I guess it's a point of view thing. Very different mindsets. So it would be more interesting knowing why, but I'm at a loss here. Why should I wrap simplest code with boilerplate? OK, maybe too late, since I need to write several lines of boilerplate to just say hello world. People argue that it's just a template that wraps the program. OK, but now it's something more fine-grained: every function must be wrapped. The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration. I mean, why are you writing a kleenex program in Java? See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?" Do you not want to declare a return type for your functions either? If there isn't a return value, I don't. Java's checked exceptions are just a way to return multiple types from your methods: a success value and a failure values. Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions?
  - ragnese 6y ago
    > The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration. As you already mentioned, that ship has sailed the second you decided to use Java. Every function already has to be wrapped in `class`, which is obnoxious. > See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?" My point wasn't celebrating boilerplate. It's about having a statically typed language. If it's too much to either add `throws Exception` to your function signature or to write a try {} catch {} block, then it must certainly already be too much to write `class MyClass { void myMethod() }`, no? > If there isn't a return value, I don't. You still have to write `void`, don't you? And checked exceptions are supposed to be something you want to force on callers of your code- like a return value. You don't want to return anything? Then return `void` and don't throw any checked exceptions. > Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions? Because it's part of your API. If you write: `int fooMethod(int input) {...}` Then you are saying "If you call `fooMethod` with an int you will get an int." If you always throw an exception on input == 3, then your API is now lying. You should either return a type that encodes the possibility of not being an int OR throw a (checked) InputWasThreeException, to be honest to your caller. Java is a poor language. Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately.
tedyoung 6y ago
I've never heard the term "kleenex program", what does that mean?
- Someone 6y ago
  You write it, use it once, then throw it away.
- deleted 6y ago
  [deleted]
zmmmmm 6y ago
> let's say I'm writing a kleenex program to explore some feature. Not nice if you make me feel all kind of boilerplate. Use Groovy. Seriously, you can code it up with zero boilerplate, use the REPL, notebooks, etc to get your idea into shape, all with 100% interop with your Java libraries. When you are done, if parts of it should graduate to "real code", you can pretty easily port it over or keep parts of it in Groovy and just take the elements over that need to be Java for robustness, etc. This is actually my standard workflow in development now.