What are the difference in usage between Either and Except in Haskell?
up vote
4
down vote
favorite
I have a class that can be created from several arguments in Haskell which requires some complex validation of those arguments. Currently I have something like
makeAThingExcept :: String -> String -> ... String -> Except ThingError AThing
makeAThingExcept s1 s2 ... = do
unless (s1CheckPasses s1) (throwError (BadS1 s1))
...
data ThingError = BadS1 String ...
instance Show ThingError where
show (BadS1 s) = "Bad S1: " ++ s
makeAThing :: String -> String -> ... String -> AThing
makeAThing s1 s2 ... = case runExcept (makeAThingExcept s1 s2 ...) of
Right thing -> thing
Left err -> error (show err)
Setting aside whether there is a better way to do this by using more specific types than String as arguments to makeAThingExcept, is there a reason to prefer Except over Either in a case like this? What are the differences here between the capabilities and idiom of Except vs Either?
haskell error-handling exception-handling user-input
asked Nov 7 at 14:31
orome
13.5k22101233
add a comment |
up vote
4
down vote
favorite
I have a class that can be created from several arguments in Haskell which requires some complex validation of those arguments. Currently I have something like
makeAThingExcept :: String -> String -> ... String -> Except ThingError AThing
makeAThingExcept s1 s2 ... = do
unless (s1CheckPasses s1) (throwError (BadS1 s1))
...
data ThingError = BadS1 String ...
instance Show ThingError where
show (BadS1 s) = "Bad S1: " ++ s
makeAThing :: String -> String -> ... String -> AThing
makeAThing s1 s2 ... = case runExcept (makeAThingExcept s1 s2 ...) of
Right thing -> thing
Left err -> error (show err)
Setting aside whether there is a better way to do this by using more specific types than String as arguments to makeAThingExcept, is there a reason to prefer Except over Either in a case like this? What are the differences here between the capabilities and idiom of Except vs Either?
haskell error-handling exception-handling user-input
asked Nov 7 at 14:31
orome
13.5k22101233
2
It probably comes down what type class instances are defined forExcept; you can convert betweenExceptandEitherusingexceptandrunExcept.
– chepner
Nov 7 at 14:49
@chepner Ah, so there's some fluidity there, wrt. tuningExceptvsEitherdepending on context.
– orome
Nov 7 at 14:57
Here in my package, FWIW, getting a validAThingis really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of makingAThings.
– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifyingAThings correctly).
– orome
Nov 7 at 14:58
1
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the nameExceptTwas introduced to provide a type that was semantically devoted to error handling, as opposed toEitherwhich is the generic way to define sum types, only one application of which is to provide error-handling semantics.
– chepner
Nov 7 at 15:04
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I have a class that can be created from several arguments in Haskell which requires some complex validation of those arguments. Currently I have something like
makeAThingExcept :: String -> String -> ... String -> Except ThingError AThing
makeAThingExcept s1 s2 ... = do
unless (s1CheckPasses s1) (throwError (BadS1 s1))
...
data ThingError = BadS1 String ...
instance Show ThingError where
show (BadS1 s) = "Bad S1: " ++ s
makeAThing :: String -> String -> ... String -> AThing
makeAThing s1 s2 ... = case runExcept (makeAThingExcept s1 s2 ...) of
Right thing -> thing
Left err -> error (show err)
Setting aside whether there is a better way to do this by using more specific types than String as arguments to makeAThingExcept, is there a reason to prefer Except over Either in a case like this? What are the differences here between the capabilities and idiom of Except vs Either?
haskell error-handling exception-handling user-input
asked Nov 7 at 14:31
orome
13.5k22101233
I have a class that can be created from several arguments in Haskell which requires some complex validation of those arguments. Currently I have something like
makeAThingExcept :: String -> String -> ... String -> Except ThingError AThing
makeAThingExcept s1 s2 ... = do
unless (s1CheckPasses s1) (throwError (BadS1 s1))
...
data ThingError = BadS1 String ...
instance Show ThingError where
show (BadS1 s) = "Bad S1: " ++ s
makeAThing :: String -> String -> ... String -> AThing
makeAThing s1 s2 ... = case runExcept (makeAThingExcept s1 s2 ...) of
Right thing -> thing
Left err -> error (show err)
Setting aside whether there is a better way to do this by using more specific types than String as arguments to makeAThingExcept, is there a reason to prefer Except over Either in a case like this? What are the differences here between the capabilities and idiom of Except vs Either?
haskell error-handling exception-handling user-input
haskell error-handling exception-handling user-input
asked Nov 7 at 14:31
orome
13.5k22101233
asked Nov 7 at 14:31
orome
13.5k22101233
asked Nov 7 at 14:31
orome
13.5k22101233
asked Nov 7 at 14:31
orome
13.5k22101233
asked Nov 7 at 14:31
orome
13.5k22101233
13.5k22101233
2
It probably comes down what type class instances are defined forExcept; you can convert betweenExceptandEitherusingexceptandrunExcept.
– chepner
Nov 7 at 14:49
@chepner Ah, so there's some fluidity there, wrt. tuningExceptvsEitherdepending on context.
– orome
Nov 7 at 14:57
Here in my package, FWIW, getting a validAThingis really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of makingAThings.
– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifyingAThings correctly).
– orome
Nov 7 at 14:58
1
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the nameExceptTwas introduced to provide a type that was semantically devoted to error handling, as opposed toEitherwhich is the generic way to define sum types, only one application of which is to provide error-handling semantics.
– chepner
Nov 7 at 15:04
add a comment |
2
It probably comes down what type class instances are defined forExcept; you can convert betweenExceptandEitherusingexceptandrunExcept.
– chepner
Nov 7 at 14:49
@chepner Ah, so there's some fluidity there, wrt. tuningExceptvsEitherdepending on context.
– orome
Nov 7 at 14:57
Here in my package, FWIW, getting a validAThingis really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of makingAThings.
– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifyingAThings correctly).
– orome
Nov 7 at 14:58
1
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the nameExceptTwas introduced to provide a type that was semantically devoted to error handling, as opposed toEitherwhich is the generic way to define sum types, only one application of which is to provide error-handling semantics.
– chepner
Nov 7 at 15:04
2
2
It probably comes down what type class instances are defined for
Except; you can convert between Except and Either using except and runExcept.– chepner
Nov 7 at 14:49
It probably comes down what type class instances are defined for
Except; you can convert between Except and Either using except and runExcept.– chepner
Nov 7 at 14:49
@chepner Ah, so there's some fluidity there, wrt. tuning
Except vs Either depending on context.– orome
Nov 7 at 14:57
@chepner Ah, so there's some fluidity there, wrt. tuning
Except vs Either depending on context.– orome
Nov 7 at 14:57
Here in my package, FWIW, getting a valid
AThing is really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of making AThings.– orome
Nov 7 at 14:58
Here in my package, FWIW, getting a valid
AThing is really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of making AThings.– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifying
AThings correctly).– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifying
AThings correctly).– orome
Nov 7 at 14:58
1
1
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the name
ExceptT was introduced to provide a type that was semantically devoted to error handling, as opposed to Either which is the generic way to define sum types, only one application of which is to provide error-handling semantics.– chepner
Nov 7 at 15:04
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the name
ExceptT was introduced to provide a type that was semantically devoted to error handling, as opposed to Either which is the generic way to define sum types, only one application of which is to provide error-handling semantics.– chepner
Nov 7 at 15:04
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
As noted in the comments, it's easy to convert between Except & Either. The runtime representation is the same, even.
I would always choose to use Either. It's ubiquitous in libraries. I very rarely see Except.
Except is a special case of ExceptT, which you will see in libraries. If you find yourself writing a lot of functions with Reader SomeType (Either e a) or IO (Either e a) or Monad m => m (Either e a), then you might want to consider ExceptT. It's fine not to worry about it until then - Either is easier to use until it isn't.
answered Nov 7 at 15:44
bergey
2,003412
I have a follow up question.
– orome
4 hours ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
As noted in the comments, it's easy to convert between Except & Either. The runtime representation is the same, even.
I would always choose to use Either. It's ubiquitous in libraries. I very rarely see Except.
Except is a special case of ExceptT, which you will see in libraries. If you find yourself writing a lot of functions with Reader SomeType (Either e a) or IO (Either e a) or Monad m => m (Either e a), then you might want to consider ExceptT. It's fine not to worry about it until then - Either is easier to use until it isn't.
answered Nov 7 at 15:44
bergey
2,003412
I have a follow up question.
– orome
4 hours ago
add a comment |
up vote
2
down vote
accepted
As noted in the comments, it's easy to convert between Except & Either. The runtime representation is the same, even.
I would always choose to use Either. It's ubiquitous in libraries. I very rarely see Except.
Except is a special case of ExceptT, which you will see in libraries. If you find yourself writing a lot of functions with Reader SomeType (Either e a) or IO (Either e a) or Monad m => m (Either e a), then you might want to consider ExceptT. It's fine not to worry about it until then - Either is easier to use until it isn't.
answered Nov 7 at 15:44
bergey
2,003412
I have a follow up question.
– orome
4 hours ago
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
As noted in the comments, it's easy to convert between Except & Either. The runtime representation is the same, even.
I would always choose to use Either. It's ubiquitous in libraries. I very rarely see Except.
Except is a special case of ExceptT, which you will see in libraries. If you find yourself writing a lot of functions with Reader SomeType (Either e a) or IO (Either e a) or Monad m => m (Either e a), then you might want to consider ExceptT. It's fine not to worry about it until then - Either is easier to use until it isn't.
answered Nov 7 at 15:44
bergey
2,003412
As noted in the comments, it's easy to convert between Except & Either. The runtime representation is the same, even.
I would always choose to use Either. It's ubiquitous in libraries. I very rarely see Except.
Except is a special case of ExceptT, which you will see in libraries. If you find yourself writing a lot of functions with Reader SomeType (Either e a) or IO (Either e a) or Monad m => m (Either e a), then you might want to consider ExceptT. It's fine not to worry about it until then - Either is easier to use until it isn't.
answered Nov 7 at 15:44
bergey
2,003412
answered Nov 7 at 15:44
bergey
2,003412
answered Nov 7 at 15:44
bergey
2,003412
answered Nov 7 at 15:44
bergey
2,003412
2,003412
I have a follow up question.
– orome
4 hours ago
add a comment |
I have a follow up question.
– orome
4 hours ago
I have a follow up question.
– orome
4 hours ago
I have a follow up question.
– orome
4 hours ago
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53191510%2fwhat-are-the-difference-in-usage-between-either-and-except-in-haskell%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
It probably comes down what type class instances are defined for
Except; you can convert betweenExceptandEitherusingexceptandrunExcept.– chepner
Nov 7 at 14:49
@chepner Ah, so there's some fluidity there, wrt. tuning
ExceptvsEitherdepending on context.– orome
Nov 7 at 14:57
Here in my package, FWIW, getting a valid
AThingis really essential, and entering valid args can be a bit tricky. So failure from user input (e.g. from a typo) can be common; but in code, something would have had to go quite wrong with whatever was generating the arguments: code that supplied bad arguments would be doing a bad job of makingAThings.– orome
Nov 7 at 14:58
So, naively, the former case is like an "either" or even a "maybe" (it could happen fix it and try again), while the latter is closer to an "exception" (your code isn't specifying
AThings correctly).– orome
Nov 7 at 14:58
1
You'll have to wait for someone who actually knows to provide an answer :) I think the only real difference is that the name
ExceptTwas introduced to provide a type that was semantically devoted to error handling, as opposed toEitherwhich is the generic way to define sum types, only one application of which is to provide error-handling semantics.– chepner
Nov 7 at 15:04