If you ask yourself what the meaning of the word 'exception' is and then consider how many failures are exceptional, then one quickly realises that exceptions are the worst thing you could use to represent expected failure conditions.

The only time we should throw (or even pass around) exceptions is if there isn't a slot in the co-domain to inject a value in to.

▲

veleon 2 days ago | parent | next [-]

I think OP means using Result<T> where Right in the Either is always implied to be Exception, much like Fin<A> in language-ext [0]

[0] https://louthy.github.io/language-ext/LanguageExt.Core/Monad...

	▲	louthy 2 days ago \| parent [-]
		I think you mean Left. And Left in Fin is Error, which has two subtypes: Expected and Exceptional, along with bespoke matching primitives for exceptional and non-exceptional errors (for the reasons I outlined) I understood what they meant, Exception is still a poor type for declarative error handling, because it’s unclear whether an event is truly exceptional.

▲

naasking 2 days ago | parent | prev [-]

The dangers and pitfalls of exceptions are completely irrelevant if all you're doing is using an exception as a value and not for control flow.

▲

louthy 2 days ago | parent [-]

It’s not about danger it’s about being declarative. That’s kinda the point of using these ‘result’ types: you’re fully declaring the codomain of the function — barring exceptions — and so if your codomain is augmented with Exception then it’s pretty hard to know whether all exceptions will be returned in value form, or just exceptional exceptions! It’s fails the declarative test.

	▲	naasking a day ago \| parent [-]
		It's not hard at all: a return type of Result is when it's returned in value form.