Groovy TryCatch class

gistfile1.groovy

    public static def _try(attempt) {
        return new TryCatch(attempt: attempt)
    }

    public static class TryCatch {

        def attempt

        public def _catch(clos) {
            try {
                return attempt();
            } catch (Exception e) {
                return clos(e);
            }
        }

        public def getCatch() {
            return _catch { null }
        }
    }

/* USAGE */

def caption = _try { very.long.gpath.find {it.name == "expression"}?.with?.array.operation[0] }._catch { "" }

// null default
[
    width: _try { attrs.width as int }.catch,
    height: _try { attrs.height as int }.catch,
]

Yes, in those examples that's quite sufficient. But the original version follows try { ... } catch { ... } semantics. Another example:

def caption = _try {
        http.get("[caption-url]") 
    }._catch {
        it instanceof TimeoutException ? "timeout" : "something else" 
    }

or

def log = loggger.&error.curry("Computation failed")
def result = _try {
        new Computator().looongComputation()
    }._catch(
        log >> { new DefaultComputationResult() } 
    )

This works too:

def tryCatch = { Closure test, Closure defVal = {null} ->
    try {
        test()
    } catch (e) {
        defVal(e)
    }
}

println tryCatch { "foo" }
println tryCatch { throw new Exception() }
println tryCatch({ throw new Exception() }, { "bar" })
println tryCatch({ throw new Exception() }, { e ->
    switch(e) {
        case RuntimeException: 'uncheckedBar'; break;
        case Exception: 'checkedBar'; break;
        default : 'evilBar'
    }
})
// prints
// foo
// null
// bar
// checkedBar

To be a bit more clear, while I do find this useful (I've done something similar a couple of times), copying language semantics using any metaprogramming/monkey patching idioms is very brittle, if you ever want others to touch and maintain your code. I don't see the real benefit beyond convenience of creating a construct for try..catch that looks as close to the real one as possible but has a single point of return to help setting a variable or whatnot. Sure, convenience all around is nice so I'm willing to let this reasoning go past me - it's just something I wouldn't do.

What really is bad though is that the try..catch class doesn't really convey the meaning of the calling structure. To circumvent this, one would still need to wrap that class onto a helper closure to "name" it properly so that it would produce clean code. As an example of this, in my first comment I used the word "optional" to convey the meaning and function of the structure. Also now that you have a try..catch, what about try..catch..finally?

Or while you're at it, what about JDK7's try-with-resources which looks like this:

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    // do whatever
}

or multi-catch (shamelessly copied from the Interwebz):

try {
    if (number.length() > 5) {
        throw new IllegalArgumentException();
    }
    Integer.parseInt(number);
} catch (NumberFormatException | IllegalArgumentException e) {
    e.printStackTrace();
}

Wouldn't it be more beneficial to try to emulate this features instead of just reinventing the wheel? You're more likely to find people who know about JDK7's native features than people who have enough of an eyeball to see that your try..catch isn't the one they've used for years (ok ok, this is an exaggeration).

While I agree with several of your points, and note that this was rather an exercise in bending Groovy towards more "core language-like" constructs, this point I do not understand:

What really is bad though is that the try..catch class doesn't really convey the meaning of the calling structure.

It is not the class that does not convey the structure, but rather how the empty catch is used in the calling code. An try {} without catch or finally is disallowed in Java, so natural way to write that would be __try { something() }.catch { null }.

Also, the Java 7 solutions still don't address what this thought experiment does: you still can't return a value from try-catch.

Also, please point me to where these "metaprogramming/monkey patching idioms" are in the above code?

Also now that you have a try..catch, what about try..catch..finally?

Did cross my mind. Working on it... ;)