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.

Typesafe Config contribution of new feature .. "required includes"

Phew.

It's taken ages but I've finally managed to finish my contribution of a long standing functional enhancement to Typesafe config.

The new feature allows one to specify whether included resources are optional or mandatory. By default when Typesafe Config encounters a resource that it can't find then it carries on silently; this is by design.

However, often we want Typesafe Config to abort if certain includes are not found, and that's what I've added by way of a new keyword `required`.

The details of the change are here https://github.com/typesafehub/config/pull/421

The syntax for this is ...

include required("foo.conf")
include required(file("foo.conf"))
include required(classpath("foo.conf"))
include required(url("http://localhost/foo.conf"))

Introducing ClasspathHell - Classpath collision mayhem detector

Think your build is stable and repeatable? Think again.

First release of https://github.com/portingle/classpathHell

It's far too easy to end up with multiple copies of a class or resource on your classpath leading to difficult to trace runtime errors that due to classpath ordering instability might not show up until late in your release cycle, or possibly even production.

Don't let that happen - just use this detector.

An excellent example is that Dropwizard and Codahale metrics have the same fully qualified class names, but with different interfaces and different implementations.

Google QUIC, a better web protocol?

A friend recently drew my attention to Google's networking innovation, QUIC, Google's alternative to HTTPS over TCP. It's a better secure fault tolerant protocol than TCP for many usages.

My greetings contacted me because he remembered that I had done something rather similar ten years ago at a bank, even down to their use of forward error correction (FEC).

TCP slow start problem was a big concern for us as our traffic was really bursty and WAN based, but time sensitive and we couldn't afford the slow start.

Both Google and myself used a reliable UDP instead of TCP. But QUIC is far more sophisticated, my approach didn't bother with in-built security, multiplexing or fairness.

My approach did however solve the problem we had which was low latency for  high bandwidth but bursty comms.

If your are interested in FEC then this may be of interest https://tools.ietf.org/html/rfc3453

The trick to reliable big throughput low latency wan comms was dumping large numbers of datagrams onto the network optimistically but including FEC to reduce the risk of loss in transit and then for belts and braces we fall back to a rarely  used resend protocol.

Of course on a corp network this works well but as the network deteriorates then the perf will degrade and approach TCP, or worse.

Anyway that work was great fun and it's interesting to see Google using similar approaches.

It'salso interesting to note how because Google have such a large browser market share and a webservices market share, they are able to fire up innovations like this doing blue/green deploys or whatever they need in order to prototype on a large scale, gathering great metrics along the way.

If there were a few good open source QUIC impls then it might be really useful in many projects. Chrome supports it and all Google services expect it. See also the Caddy webserver which looks very interesting.

Worth keeping an eye on.