Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Triple curly braces results in `Exception: UnexpectedEvent {_received = Just (EventMappingStart Nothing), _expected = Nothing}` #129

Closed
chrissound opened this issue Mar 1, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@chrissound
Copy link

commented Mar 1, 2018

yaml 0.8.25
stack lts-10.0

I don't think my below example is valid Yaml, however I would think it would rather return Nothing rather than an exception.

apiVersion: apps/v1
metadata:
  name: diyapp
  labels:
    appId: {{{appId}}}
import Control.Monad
import Data.Monoid
import Options.Applicative
import System.IO
import System.Process
import System.Directory
import Control.Monad.Extra
import qualified Data.Aeson as Aeson
import qualified Data.Yaml as Yaml
import GHC.Generics
import qualified Data.ByteString.Lazy as B
  appConfig' <- B.readFile "config.json" >>= return . Aeson.decode :: IO (Maybe AppConfig)
  deploymentConfig' <- Yaml.decodeFile "deployment.yaml" :: IO (Maybe Yaml.Value)
  case (
    appConfig',
    deploymentConfig'
    ) of
    (
      Just appConfig,
      Just deploymentConfig
      ) -> do
        print appConfig
        print deploymentConfig
    _-> error "config file invalid"

@bitemyapp bitemyapp changed the title Tripple curly braces results in `Exception: UnexpectedEvent {_received = Just (EventMappingStart Nothing), _expected = Nothing}` Triple curly braces results in `Exception: UnexpectedEvent {_received = Just (EventMappingStart Nothing), _expected = Nothing}` Mar 1, 2018

@bitemyapp

This comment has been minimized.

Copy link
Collaborator

commented Mar 1, 2018

You want the parser to special-case parse failure for something that isn't valid YAML? I think it would make more sense to handle this in a similar manner to how Pandoc 2.0+ handles the extended markdown variants with feature flagging and an extended parser.

I'm not sure how well that would jive with the use of libyaml though.

Personal/practical aside: I value this library as a simple and safe way to use yaml because it's simple and restricts what it does to a safe subset of YAML that is basically just Data.Aeson.Value.

That said I'm not the author or even a maintainer of this library, only a user.

@sol

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2018

@chrissound you can get your desired behavior by using decodeFileEither instead of decodeFile. decodeFile only returns Nothing if parseJSON fails. Other exceptions (e.g. IO exceptions and YAML syntax errors) are not handled. I think this is mostly for historic reasons and changing it now would be a breaking change that is not detected by the type system.

@sol

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2018

What we could do is deprecate decodeFile in favor of decodeFileEither; or change the type of decodeFile to IO a so that it's very clear from the type that this function throws exceptions.

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Mar 19, 2018

I'm in favor of deprecating; I've known for a long time that it's a code smell to use decodeFile instead of decodeFileEither, but frankly had forgotten why.

snoyberg added a commit that referenced this issue Mar 19, 2018

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Jul 9, 2018

Deprecation occurred in 0.8.29, closing.

@snoyberg snoyberg closed this Jul 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.