Could do us a favour and run the benchmarks for performance on this change and against master on a non-shared machine?

The reason I didn't fix this originally was I was scared of a slow down by having another try/catch in a hot code path. The performance report in the travis ci build.......show making this change makes the code faster which is :spocks_eyebrow.gif:

I find these benchmark quite useless - results sometimes vary vastly on consecutive runs.
Nevertheless, here you are:
https://gist.github.com/Furgas/d57d0658de87aff74e078623105841c7

Can also be of use:
https://gist.github.com/Furgas/d19ca419969337a341b58a3d6eb7b9ce

I intend to merge this, regardless of any performance benchmark, because it's a bug that should be fixed.

We could probably move the code inside make into an internal doMake method, so we only have one try / catch around the top-most make instead of every nested make.

@Danack @trowski Opinions?

I've found benchmarks on Travis to be dubious at best, the try/catch is definitely slower, but not enough that it's even worth discussing.

As for an internal doMake function, maybe it's something to look at when I (or someone else) migrates this lib to 7.1+.