search

denibertovic / docker-hs

A Haskell library for the Docker Engine API
BSD 3-Clause "New" or "Revised" License
76 stars 48 forks source link

Use exceptions instead of Either in Docker.Client.API #47

Closed dschoepe closed 6 years ago

dschoepe commented 6 years ago

I think the use of Either DockerError x as the return type of all the Docker.Client.API.* functions makes the API somewhat cumbersome to use, since it requires pattern-matching on each return value before using it.

Instead I would suggest throwing an exception whenever a DockerError is returned in the current version. I can volunteer to implement this change, but wanted to check if there was another reason for the current design decision that I'm missing.

jprider63 commented 6 years ago

Thanks for the request @dschoepe. Unfortunately, I'm against throwing exceptions in this situation. It makes control flow unintuitive and hides failure cases from the function types.

If you don't want to pattern match on every call, you could use the ErrorT monad transformer (it looks like this has been deprecated for ExceptT). You could also wrap the calls with a function that throws an exception on a DockerError. Something like: 

errorToException = fmap (either (throw . DockerException) id)
denibertovic commented 6 years ago

I'm with @jprider63 on this one. I like having the information about the failure in the types, at least for the docker client specific errors which we can always add more of, and I'm not convinced that using exceptions would make a cleaner API.... Though I could change my mind in the future, this is where I stand now.