Hacker News Reader

Comment by meddlepal | Hacker News Reader

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.

View on HN

> Checked exceptions

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

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.

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().

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.

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.

  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-...

> 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.

Can you show an example of how this can be done?

> 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.

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

In 8 it's at least easier to wrap checked exceptions in unchecked

https://github.com/benjiman/expressions/blob/master/src/test...

implementation

https://github.com/benjiman/expressions/blob/master/src/main...

+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.

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

> 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.

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.

> 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.

I really don't have a problem with erased generics for the same reason a poster below pointed out.

> Checked Exceptions and null

I hear you.

Reply on news.ycombinator.com