4 ms·

Checked Exceptions and null. I write a lot of Java and I generally enjoy the language, but those two things; if Oracle could fix those somehow I would be extrem

Checked Exceptions and null. I write a lot of Java and I generally enjoy the language, but those two things; if Oracle could fix those somehow I would be extremely pleased. I'm so tired of writing null checks and I hope Optional<T> is not the final answer since it too can be a null due to programmer error. I am really worried about Optional getting abused in Java 8... Actually, I waffle on checked exceptions; it seems every 8 months or so I have a different opinion of them. Right now they suck.

stusmall 13y ago
I'm the same way with checked exceptions. Right now I am in the pro-camp... but just give me a little bit. I am about to start a greenfield jvm project so I think I will be anti soon... but once its mature and I'm in bug fix mode I'll be heading back to the pro-camp.
yawz 13y ago
> Checked Exceptions and null I hear you.
CodeMage 13y ago
> Checked Exceptions and null. Let's not forget about type-erasure generics. And the existence of arrays. And the fact that people still use arrays.
- zeroDivisible 13y ago
  Exactly - checked exceptions is more of an policy / code style decision, null and NPE - roughly the same and in the end your spider sense just knows where to expect it. But type-erasure of generics - that's the decision with which we will need to live till the end of time. - no multiple implementation of same generic interface - http://stackoverflow.com/questions/2723397/java-generics-what-is-pecs - small performance hits.. - casts - a lot more but I'm just sleepy right now. I use and like Java, I love the backwards compatibility which it has - but there are times when crust can be removed with scalpel - and if not, you will need an jackhammer later.
- dragonwriter 13y ago
  > Let's not forget about type-erasure generics. Type-erasure generics are a fortuitous platform decision, because its what enables languages on the platform to have a good interop story while still having a more robust type system than Java does -- case in point, Scala, and why the .NET version died.
- meddlepal 13y ago
  I really don't have a problem with erased generics for the same reason a poster below pointed out.
chriswarbo 13y ago
> Checked exceptions It always bothered me that Java forces me to explicitly handle/rethrow exceptions, yet happily overflows my ints without batting an eyelid.
tieTYT 13y ago
I like checked exceptions in certain situations. I generally dislike the checked ones that come with Java ^1, but it can be very useful to create your own. I had a situation where I was interacting with an API that would sometimes fail over things I could not control. But, the code responsible for interfacing with the API didn't have the context for handling those errors. Initially I threw a Runtime (ie: non compile time) exception. After going to production I realized that these were bubbling up to the UI and giving the user very intimidating error messages. So I changed the exception to a Compile time exception and then the compiler caught every place I let the error slip through to the UI. In my opinion it saved me a lot of time and made my code easier to maintain. 1: EG: Who is Java to say that this IOException should be handled in code? Perhaps this IOException should not happen and requires a developer's intervention.
- brianpgordon 13y ago
  InterruptedException is the worst. I know that I'm not calling Thread.interrupt() so why do I need to handle that case? It's already hard enough to reason about multithreaded code without worrying about future-proofing it for some case where it's somehow convenient for another developer to use Thread.interrupt().
- mercurial 13y ago
  I used to think checked exceptions were mostly an annoyance. Then one day, when working with a library doing I/O in Haskell, I realized that I couldn't pattern-match on whatever exceptions it may throw because I didn't know what they were and the type system was no help. Since then, I learned to live with the verbosity.
wsc981 13y ago
I'm so tired of writing null checks ... Could the null checks of Java be compared to the ones used in C#? My C# code is often littered with ternary operators to deal with null values. And that's still not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. I guess I kinda wonder if I could avoid the null checks in C# somehow ... I figured using a design by contract approach might be used to reduce the null checks somewhat. [0]: http://stackoverflow.com/questions/156395/sending-a-message-to-nil http://stackoverflow.com/questions/156395/sending-a-message-...
- jussij 13y ago
  > I guess I kinda wonder if I could avoid the null checks in C# somehow Without seeing your code it is hard to say, but using an object extension might work? On many occasions I've used object extensions to hide checking code deep inside the extension. C# really got that feature right.
  - creatio 13y ago
    Can you show an example of how this can be done?
- RyanZAG 13y ago
  > not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. It's definitely NOT awesome. This stupid behaviour causes bugs all the time as you think you're doing an action but it's actually a no-op because something else failed and you get a nil. An NPE is awesome - it crashes immediately and you know exactly what is wrong. A silent no-op is the worst thing to debug.
- rpeden 13y ago
  Have you found C#'s null coalescing operator useful in these situations at all? I've found it to be quite handy. http://msdn.microsoft.com/en-us/library/ms173224.aspx http://msdn.microsoft.com/en-us/library/ms173224.aspx
benjiweber 13y ago
In 8 it's at least easier to wrap checked exceptions in unchecked https://github.com/benjiman/expressions/blob/master/src/test/java/uk/co/benjiweber/expressions/ExceptionsTest.java https://github.com/benjiman/expressions/blob/master/src/test... implementation https://github.com/benjiman/expressions/blob/master/src/main/java/uk/co/benjiweber/expressions/Exceptions.java https://github.com/benjiman/expressions/blob/master/src/main...
aragot 13y ago
+1. If only they had introduced syntactic sugars for nulls, like user?getAddress()?getStreet(). It just doesn't have to be so painful. Writing functions used to be one of them and I'm happy it's solved.
riffraff 13y ago
FWIW, I have found using findbugs and @Nullable/@NotNull to be a blessing.

stusmall 13y ago

I'm the same way with checked exceptions. Right now I am in the pro-camp... but just give me a little bit. I am about to start a greenfield jvm project so I think I will be anti soon... but once its mature and I'm in bug fix mode I'll be heading back to the pro-camp.

yawz 13y ago

> Checked Exceptions and null I hear you.

CodeMage 13y ago

> Checked Exceptions and null. Let's not forget about type-erasure generics. And the existence of arrays. And the fact that people still use arrays.

zeroDivisible 13y ago
Exactly - checked exceptions is more of an policy / code style decision, null and NPE - roughly the same and in the end your spider sense just knows where to expect it. But type-erasure of generics - that's the decision with which we will need to live till the end of time. - no multiple implementation of same generic interface - http://stackoverflow.com/questions/2723397/java-generics-what-is-pecs - small performance hits.. - casts - a lot more but I'm just sleepy right now. I use and like Java, I love the backwards compatibility which it has - but there are times when crust can be removed with scalpel - and if not, you will need an jackhammer later.
dragonwriter 13y ago
> Let's not forget about type-erasure generics. Type-erasure generics are a fortuitous platform decision, because its what enables languages on the platform to have a good interop story while still having a more robust type system than Java does -- case in point, Scala, and why the .NET version died.
meddlepal 13y ago
I really don't have a problem with erased generics for the same reason a poster below pointed out.

chriswarbo 13y ago

> Checked exceptions It always bothered me that Java forces me to explicitly handle/rethrow exceptions, yet happily overflows my ints without batting an eyelid.

tieTYT 13y ago

I like checked exceptions in certain situations. I generally dislike the checked ones that come with Java ^1, but it can be very useful to create your own. I had a situation where I was interacting with an API that would sometimes fail over things I could not control. But, the code responsible for interfacing with the API didn't have the context for handling those errors. Initially I threw a Runtime (ie: non compile time) exception. After going to production I realized that these were bubbling up to the UI and giving the user very intimidating error messages. So I changed the exception to a Compile time exception and then the compiler caught every place I let the error slip through to the UI. In my opinion it saved me a lot of time and made my code easier to maintain. 1: EG: Who is Java to say that this IOException should be handled in code? Perhaps this IOException should not happen and requires a developer's intervention.

brianpgordon 13y ago
InterruptedException is the worst. I know that I'm not calling Thread.interrupt() so why do I need to handle that case? It's already hard enough to reason about multithreaded code without worrying about future-proofing it for some case where it's somehow convenient for another developer to use Thread.interrupt().
mercurial 13y ago
I used to think checked exceptions were mostly an annoyance. Then one day, when working with a library doing I/O in Haskell, I realized that I couldn't pattern-match on whatever exceptions it may throw because I didn't know what they were and the type system was no help. Since then, I learned to live with the verbosity.

wsc981 13y ago

I'm so tired of writing null checks ... Could the null checks of Java be compared to the ones used in C#? My C# code is often littered with ternary operators to deal with null values. And that's still not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. I guess I kinda wonder if I could avoid the null checks in C# somehow ... I figured using a design by contract approach might be used to reduce the null checks somewhat. [0]: http://stackoverflow.com/questions/156395/sending-a-message-to-nil http://stackoverflow.com/questions/156395/sending-a-message-...

jussij 13y ago
> I guess I kinda wonder if I could avoid the null checks in C# somehow Without seeing your code it is hard to say, but using an object extension might work? On many occasions I've used object extensions to hide checking code deep inside the extension. C# really got that feature right.
- creatio 13y ago
  Can you show an example of how this can be done?
RyanZAG 13y ago
> not as safe as the Objective-C approach where one can just send messages to nil[0] which is really awesome imo. It's definitely NOT awesome. This stupid behaviour causes bugs all the time as you think you're doing an action but it's actually a no-op because something else failed and you get a nil. An NPE is awesome - it crashes immediately and you know exactly what is wrong. A silent no-op is the worst thing to debug.
rpeden 13y ago
Have you found C#'s null coalescing operator useful in these situations at all? I've found it to be quite handy. http://msdn.microsoft.com/en-us/library/ms173224.aspx http://msdn.microsoft.com/en-us/library/ms173224.aspx

benjiweber 13y ago

In 8 it's at least easier to wrap checked exceptions in unchecked https://github.com/benjiman/expressions/blob/master/src/test/java/uk/co/benjiweber/expressions/ExceptionsTest.java https://github.com/benjiman/expressions/blob/master/src/test... implementation https://github.com/benjiman/expressions/blob/master/src/main/java/uk/co/benjiweber/expressions/Exceptions.java https://github.com/benjiman/expressions/blob/master/src/main...

aragot 13y ago

+1. If only they had introduced syntactic sugars for nulls, like user?getAddress()?getStreet(). It just doesn't have to be so painful. Writing functions used to be one of them and I'm happy it's solved.

riffraff 13y ago

FWIW, I have found using findbugs and @Nullable/@NotNull to be a blessing.