How do I explain the benefits of functional programming to someone who thinks that try/catch is the answer to everything?

[MrYossu]

Apologies if this isn't on-topic here, as it's not about LanguageExt specifically, but more about functional programming.

I have some code (in an ASP.NET minimal API, but I don't think that's relevant) that returns a value from an enum indicating the results of calling the API. All the code in the call is broken down into small reusable static methods that return an Either<ResponseStatus, T>. I use then in a manner similar to this...

public static async Task<IResult> DoSomething(/* params go here, including injected dependencies */) =>
  await (
    from jim in GetJim().ToAsync()
    from john in GetJohn(jim).ToAsync()
    // Other lines go here
  )
  .Match(Results.Ok, Results.BadRequest);

His reaction to this was "Why not wrap it all in a try/catch block?" I took this to mean that each of his methods would either return a value, or throw an exception, and his catch at the end would handle them.

Apart from the fact that using exceptions for non-exceptional cases, such as an incorrect parameter value, I couldn't explain to him why I preferred the approach shown above. I've come far enough learning FP to feel that this is better, but not far enough to be able to explain it.

Maybe I'm wrong. Maybe there isn't a benefit over using a big try/catch block.

Can anyone help me? Thanks

[EivindAntonsen]

There is something to be said for "honest" method signatures.

A method has an explicit input and an explicit output - but methods that throw exceptions have a third implicit output (the exception). Even more outputs if they use the out keyword. If a method does more than what the signature conveys, it is not an "honest" method. An obvious example is a very naive Divide method that takes int x, int y and simply does return x / y. It's honest until someone tries to divide by 0, and then you don't get the promised int result in return, you get an exception instead.

All of that makes code more difficult to reason with, because something different than what's specified in the contract might happen. And if you need to riddle your codebase with try/catch, it essentially clutters the control flow of your application to handle potential implicit situations that could've been handled explicitly instead (Option<int> TryDivide(int x, int y)), and your codebase isn't reliable (something different may happen in some situations).

As far as your specific example goes, there's a more appropriate construct to look into than Either for asynchronous operations and that's Aff. Look into this discussion where @louthy gave a really good example on how to use Aff with asynchronous http requests. They additionally handle try/catch automatically and bake eventual exceptions into the result so that you can .Match() the result struct like you would with an Either.

[MrYossu]

Thanks for the reply.

I tried explaining that using exceptions for validation wasn't really a good idea, but he didn't seem to be very impressed with that. I didn't phrase it in terms of honest signatures, but given his lack of interest in not using exceptions, I don't think that would have gone down very well either!

As for Aff, I have looked at it, but haven't yet converted the old code. Thanks for the reminder though.