Functional exception handling with TryCatchFinally statement helpers

I wrote something to the effect of a try catch finally statement helper in functional style so that I can shorten much of the code I'm writing for my Service Layer that connects to an SQL database.

Because of that, I found myself needing to code up a lot of try catch statements. I found this article this article on a functional exception handling and looked at the author's Bitbucket source and was inspired to write the following with a differing style from that of the author but, suiting my purposes. I'm certainly not an expert and I could be totally wrong in my approach here. I'm looking for "yes" or "no" and "here is why".

```
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Common.Helper
{
public static class FunctionalHelpers
{
public static void TryCatch(Action tryAction, Action handler)
where TE : Exception
{
try { tryAction(); }
catch (TE ex)
{
handler(ex);
}
}

public static void TryCatch(Action tryAction, TArg args, Action handler)
where TE : Exception
{
try { tryAction(args); }
catch (TE ex)
{
handler(ex);
}
}

public static void TryCatchFinally(Action tryAction, Action CatchAction, Action FinallyAction)
where TE : Exception
{
try
{
tryAction();
}
catch (TE t)
{
CatchAction(t);
}
finally
{
FinallyAction();
}
}

public static void TryCatchFinallyUsing(Action tryAction, Action CatchAction, Action FinallyAction, TUsing arg)
where TE : Exception
where TUsing : IDisposable
{
using (arg)
{
try
{
tryAction(ar

There are some smaller issues in your code, which I will mention later. But the main issue I see is that it's quite useless, since it doesn't make your code any shorter.

If you compare:

try
{
    /* some code */
}
catch (SomeException ex)
{
    /* more code */
}

with

FunctionalHelpers.TryCatch(
    () => /* some code */,
    ex => /* more code */);

then the latter might look shorter, but that's mostly an illusion. It's more complicated, it's actually longer (if you count the characters) and you could also write the original code like this:

try { /* some code */ }
catch (SomeException ex)
{ /* more code */ }

Though I'm not saying you should do that, this code looks terrible.

The point of the article you linked to was to be able to handle several different exceptions with the same code without repeating. Your methods can't do that.

Now to the minor points:

public static void TryCatch(Action tryAction, Action handler)

You should use Action instead. This way, you can easily access properties that are specific to that type of exception.

public static void TryCatch(Action tryAction, TArg args, Action handler)

I don't see much point in having overloads with args. It's usually much easier to use closures (though slightly less performant).

public static void TryCatchFinallyUsing(Action tryAction, Action CatchAction, Action FinallyAction, TUsing arg)

It seems you missed another point the article made. If you have TUsing as a simple parameter and the code that creates that object throws, it won't be caught by your CatchAction. You should have Func instead.

Also, you should consistently name parameters using camelCase, not PascalCase.

public static void TryCatch(Action tryAction, Action handler, Action FinallyAction)

This method should be called TryCatchFinally.

StackExchange Code Review Q#23310, answer score: 9