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

[chrissound]

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]

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]

@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]

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]

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]

Deprecation occurred in 0.8.29, closing.