hmm, it's not really something I invented, the first version (with the Left and Right) is directly taken from the Arrow functional library. I wonder if the name Try has been avoided in kotlin (java) because of it's keyword status.
The Try<> you mention only has one generic, which I think doesn't quite map to these Eithers
You can add a second generic parameter for the exception type if there's any reason you would want to cast down to the exception type, works fine. Just in the majority of cases Throwable is adequate so the type parameter gets omitted.
Editing to say there are actually two ways to go about it.
You say all exceptions are just the same thing, Throwable, in which case you omit the parameter. Then when someone gets one, they inspect what they got, and use when or whatever.
You generate a family of Try<T, X1>, Try<T, X1, X2>, Try<T, X1, X2, X3> classes to capture more and more separate errors.
I think you're describing a different thing entirely. Eithers typically don't contain exceptions as one of the values, they typically contain an error. You can use Eithers in kotlin as a way to avoid using exceptions in your API (whereas in Java it might be more idiomatic to handle exceptions). There's a bit more on that difference here: elizarov.medium.com/kotlin-and-exc...
Error and exception are just two words for the same thing. Sure, in Java "Error" was reserved to mean specific kinds of error which were more fatal while "Exception" was for more recoverable ones, other languages reversed this distinction or didn't have it at all, so we can basically treat them as synonyms.
Which way you then implement them is up to what's possible in the language. In Java we had the luxury of being able to throw them but in some other languages, returning different values is really the only way. In the more procedural languages, people either tended to return the error code, or return a sentinel result. In functional languages, the Try monad and similar structures were the common way to go about this.
Using such structures does not avoid using exceptions - it's another way to implement exceptions.
This is getting a bit trolly don't you think? Your original comment was about Try<> but this article is about Either<>.
Now you're explaining to me that Errors and Exceptions are the same thing - in the context of this article, and in the article posted above, they do not mean the same thing at all. Exception is being used to mean part of Java's exception handling - the things that you try / catch. Error is being used to mean a regular class like an enum or a sealed class which forms part of a standard type safe API.
As I mention above "You can use Eithers in kotlin as a way to avoid using exceptions in your API".
I think you should write an article about Try<> it might be interesting
Fair enough, you're just artificially separating the concepts.
And no, telling people how things are is not "trolling". And calling something something different doesn't really change its nature either. An error is an error, whether it's modelled by throwing, raising, returning special values, monads, or anything.
And like I already pointed out, you're not avoiding using exceptions, you're just implementing them in a different way. The exceptional condition is still there. You're not avoiding them "in your API" because you're not avoiding them at all. You're just implementing them differently. Is this different way better? Quite possibly. Especially in a language like Kotlin where you can't force people to handle the thrown ones.
I would recommend learning more than a couple of programming languages and seeing what else is out there. You'll see the common patterns between them as you pick more up.
Also, the normal use case for Either, for what it's worth, is not for error conditions, but for situations where there are two possible outcomes. Saying that an error is a second possible outcome... well, I guess that's sort of true, but usually you'd call that Try. The person reading the code is going to understand when they see Try that the alternative outcome is an error. If they see Either, they wouldn't know.
What you have invented here is typically called Try, sometimes seen as Maybe. It contains the result of an operation or an exception.
You apparently didn't know Eithers were a thing, and you sought to teach me in public that I had mistakenly re-invented a Try, named it Either, and then written a whole article about it.
I've tried to remain polite, but honestly your comments would be much more welcome on Reddit. Dev.to has a great community, and this has been a very disappointing interaction. Please get off my page
Nope, I knew Eithers were a thing as well. They're just not generally for putting an exception case as the second alternative. For that, there is Try.
And hey, I was being polite until you called what I was saying trolling. If you throw a stone, you better expect someone is going to pick it up and throw it back at you.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
hmm, it's not really something I invented, the first version (with the Left and Right) is directly taken from the Arrow functional library. I wonder if the name Try has been avoided in kotlin (java) because of it's keyword status.
The Try<> you mention only has one generic, which I think doesn't quite map to these Eithers
You can add a second generic parameter for the exception type if there's any reason you would want to cast down to the exception type, works fine. Just in the majority of cases
Throwableis adequate so the type parameter gets omitted.Editing to say there are actually two ways to go about it.
Throwable, in which case you omit the parameter. Then when someone gets one, they inspect what they got, and usewhenor whatever.Try<T, X1>,Try<T, X1, X2>,Try<T, X1, X2, X3>classes to capture more and more separate errors.I think you're describing a different thing entirely. Eithers typically don't contain exceptions as one of the values, they typically contain an error. You can use Eithers in kotlin as a way to avoid using exceptions in your API (whereas in Java it might be more idiomatic to handle exceptions). There's a bit more on that difference here: elizarov.medium.com/kotlin-and-exc...
Error and exception are just two words for the same thing. Sure, in Java "Error" was reserved to mean specific kinds of error which were more fatal while "Exception" was for more recoverable ones, other languages reversed this distinction or didn't have it at all, so we can basically treat them as synonyms.
Which way you then implement them is up to what's possible in the language. In Java we had the luxury of being able to throw them but in some other languages, returning different values is really the only way. In the more procedural languages, people either tended to return the error code, or return a sentinel result. In functional languages, the Try monad and similar structures were the common way to go about this.
Using such structures does not avoid using exceptions - it's another way to implement exceptions.
This is getting a bit trolly don't you think? Your original comment was about Try<> but this article is about Either<>.
Now you're explaining to me that Errors and Exceptions are the same thing - in the context of this article, and in the article posted above, they do not mean the same thing at all. Exception is being used to mean part of Java's exception handling - the things that you try / catch. Error is being used to mean a regular class like an enum or a sealed class which forms part of a standard type safe API.
As I mention above "You can use Eithers in kotlin as a way to avoid using exceptions in your API".
I think you should write an article about Try<> it might be interesting
Fair enough, you're just artificially separating the concepts.
And no, telling people how things are is not "trolling". And calling something something different doesn't really change its nature either. An error is an error, whether it's modelled by throwing, raising, returning special values, monads, or anything.
And like I already pointed out, you're not avoiding using exceptions, you're just implementing them in a different way. The exceptional condition is still there. You're not avoiding them "in your API" because you're not avoiding them at all. You're just implementing them differently. Is this different way better? Quite possibly. Especially in a language like Kotlin where you can't force people to handle the thrown ones.
I would recommend learning more than a couple of programming languages and seeing what else is out there. You'll see the common patterns between them as you pick more up.
Also, the normal use case for Either, for what it's worth, is not for error conditions, but for situations where there are two possible outcomes. Saying that an error is a second possible outcome... well, I guess that's sort of true, but usually you'd call that Try. The person reading the code is going to understand when they see Try that the alternative outcome is an error. If they see Either, they wouldn't know.
Go back and read your first comment:
You apparently didn't know Eithers were a thing, and you sought to teach me in public that I had mistakenly re-invented a Try, named it Either, and then written a whole article about it.
I've tried to remain polite, but honestly your comments would be much more welcome on Reddit. Dev.to has a great community, and this has been a very disappointing interaction. Please get off my page
Nope, I knew Eithers were a thing as well. They're just not generally for putting an exception case as the second alternative. For that, there is Try.
And hey, I was being polite until you called what I was saying trolling. If you throw a stone, you better expect someone is going to pick it up and throw it back at you.