More on the sad state of checked exceptions

Following on from my previous post about Java Lambdas and checked exceptions I did a bit more research.

I found a revealing analysis of what github programmers do when exception handling. 

As far as I am concerned it goes to demonstrate the failure of Java’s attitude to checked exceptions.

http://plg.uwaterloo.ca/~migod/846/current/projects/09-NakshatriHegdeThandra-report.pdf

This is well worth a read; it would seem that most developers do not respect checked exceptions at all, typically ignoring them entirely or doing nothing more than logging and swallowing.

Take a look at figures 7 and 8 of the report. Clearly a lot of catch blocks are entirely empty, however what about the ones that do a bit of printing/logging? They looked closer and found that typically when either logging/printing take place then these are typically the only operations done in the catch; so only a tiny bit better than an empty catch block.

It is hard to believe that in the vast majority of cases it is really acceptable for a program to carry on without taking any action – however that’s what we see across github. 

Quality software!

Sad state of Java Lambdas and Checked Exceptions

Was looking into Java 8's functional programming features.

I instantly came across a problem that functional programming in Java 8 is incompatible with checked exceptions. Given Java’s obsession with checked exceptions this seems bizarre.

Evidence of this is found in the Java 8 UncheckedIOException class – if you look where/how this is used in the JDK it’s clear Oracle have hacked this into place to allow them to add functional stuff to their IO libraries.

For more information see this exploration of exceptions and lambdas  … https://webcache.googleusercontent.com/search?q=cache:Rr87XOyyA9wJ:https://javadevguy.wordpress.com/2016/02/22/a-story-of-checked-exceptions-and-java-8-lambda-expressions/+&cd=8&hl=en&ct=clnk&gl=uk

It would seem that if Java programmers are going functional then they are also saying checked exceptions are effectively deprecated.

I'm no fan of checked exceptions but it would seem that Brian Goetz was aware of this in 2010 and despite that we're still in this situation. Perhaps it's the end of the road for checked exceptions?

Getting Going

I'm now checking out Golang.

Some initial bumps were due to my expectations based on having largely lived in the JVM ecosystem in recent years.

Bump 1 - artefact repositories

There is intentionally no artefact repo (no maven central) for prebuilt objects. Instead you must build all dependencies from source. Then build your app.

This approach is familiar to anyone having built a C program like Apache using configure and make. You would download the source of the app and the source of the dependencies to disk. Then one at a time, for each dependency and for the app, you build it by telling configure where the source is on disk then kick off the configure. This spits out a makefile that can be run using make to build the component. Rinse and repeat until you have an executable.

The configure/make approach gets boring quickly and due to the effort involved and the desire for reproducibility one typically hand cranks a shell script to automate everything from the download to delivering the exe. Perhaps there are some fancy modern build tools for C out there but in haven't noticed them and what I described above is still the state of play for big products like Apache.

By contrast go build downloads all the sources of the dependencies automatically and builds them in the correct order to produce the exe. Go build works out the location to download the source from by virtue of cleverly embedding the github path into the import statements.

import (
"fmt"
"github.com/user/stringutil"
)

Bump 2 - dependency versions

Sooo .. my app has some dependencies. I was expecting to have to write a file somewhere declaring the versions of the dependencies in some manner.

But, bizarrely, the basic go build pattern has none of this.

It looks like go assumes you always want the latest versions of your dependencies no matter what you might like.

If you want reproducible builds them it would seem that you either check all the third party coffee into your git repository or use some 3rd party tooling.

---

Anyway I'm finding the language fun to work in.

I like the way functions are mapped to the data structures they relate to but I've not had a chance to look at what's available for immutability or threading or io or any other such fun.

Just getting started.