{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE LambdaCase #-}
module Data.Error
  ( Error,
    -- * Error creation
    newError,
    -- *** From 'Show' and 'Exception'

    -- | These two functions can be helpful, but consider that they don’t always provide very user-friendly error messages.
    -- It is recommended that you use `addContext` to improve the messages generated by 'showToError' and 'exceptionToError'.
    showToError,
    exceptionToError,
    -- * Adding context
    addContext,
    -- * Pretty printing
    prettyError,
    -- * Unsafe unwrapping

    -- | Sometimes you want to assure that an 'Error' could not have happened at runtime,
    -- even though there is the possibility in the types.
    --
    -- In that case you can use 'expectError'/'unwrapError'.
    -- They will panic at runtime (via 'error') if there was an error.
    --
    -- You can also use 'expectIOError'/'unwrapIOError' if your code is in 'IO',
    -- which will crash with 'Exc.throwIO' instead of 'error'.
    --
    -- 'expectError'/'expectIOError' should usually be preffered, since it adds a context message.
    --
    -- These are modelled after @<https://doc.rust-lang.org/std/result/enum.Result.html#method.expect Result::expect()>@
    -- and @<https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap Result::unwrap()>@ in the rust stdlib.
    expectError,
    unwrapError,
    expectIOError,
    unwrapIOError,
    -- * Catching @Exceptions@ in 'IO'
    ifIOError,
    ifError
  )
where

import Data.Function ((&))
import Data.Text (Text)
import qualified Data.Text as Text
import GHC.Stack (HasCallStack)
import Control.Exception (Exception (displayException))
import qualified Control.Exception as Exc
import Data.Functor ((<&>))
import Data.Bifunctor (first)

-- | The canonical @Error@ type.
--
-- It can be
--
-- * created from a human-readable error message ('newError')
-- * more semantic context can be added to an existing @Error@ ('addContext')
-- * pretty-printed (`prettyError`)
newtype Error = Error [Text]

-- | The 'Show' instance exists for the user’s convenience on the REPL.
--
-- If you want to display an error, use 'prettyError' instead.
deriving instance Show Error

-- | Create an ad-hoc 'Error' from an error message.
newError :: Text -> Error
newError msg = Error [msg]

-- | Create an error from a `Show` type.
--
-- If your type implements 'Exception', it is usually better to use 'exceptionToError' instead.
-- Strings produced by 'show' are usually not very user-friendly.
--
-- Note: goes via `String`, so not efficient.
showToError :: Show a => a -> Error
showToError = newError . Text.pack . show

-- | Create an error from an 'Exception' type.
--
-- The default implementation of 'displayException' is 'show', so the same user-friendliness problems of 'showToError' apply.
--
-- Note: goes via `String`, so not efficient.
exceptionToError :: Exception exc => exc -> Error
exceptionToError = newError . Text.pack . displayException

-- | Add a higher-level context to an 'Error'.
--
-- For example, your code hits a “file not found” I/O exception.
-- Instead of propagating it unseen, you catch it and annotate it with 'addContext',
-- and describe why you wanted to open the file in the first place:
--
-- @
-- addContext "Trying to open config file"
--   $ newError "file not found: ./foo"
-- @
--
-- This way, when a user see the error, they will understand better what happened:
--
-- @
-- "Trying to open config file: file not found: ./foo"
-- @
--
-- See 'prettyError'.
addContext :: Text -> Error -> Error
addContext e (Error es) = Error $ e : es

-- | Pretty print the error.
--
-- It will print all context messages, starting with the outermost.
--
-- Example:
--
-- >>> prettyError $ newError "file not found: ./foo"
-- "file not found: ./foo"
--
-- >>> :{
--   prettyError
--     $ addContext "Trying to open config file"
--       $ newError "file not found: ./foo"
-- :}
-- "Trying to open config file: file not found: ./foo"
prettyError :: Error -> Text
prettyError (Error es) = Text.intercalate ": " es

-- | Return the value from a potentially failing computation.
--
-- Abort with the 'Error's message if it was a 'Left'.
--
-- __Panics:__ if Error
--
-- Example:
--
-- >>> unwrapError $ Left (newError "oh no!")
-- *** Exception: oh no!
-- ...
--
-- >>> unwrapError $ Right 42
-- 42
unwrapError :: HasCallStack => Either Error a -> a
unwrapError e = case e of
  Left err -> error (prettyError err & Text.unpack)
  Right a -> a

-- | Return the value from a potentially failing computation.
--
-- Abort with the error message if it was an error.
--
-- The text message is added to the 'Error' as additional context before aborting.
--
-- __Panics:__ if Error
--
-- Example:
--
-- >>> expectError "something bad happened" $ Left (newError "oh no!")
-- *** Exception: something bad happened: oh no!
-- ...
--
-- >>> expectError "something bad happened" $ Right 42
-- 42
expectError :: HasCallStack => Text -> Either Error p -> p
expectError context e = case e of
  Left err ->
    error
      ( err
          & addContext context
          & prettyError
          & Text.unpack
      )
  Right a -> a

-- | This Exception is not exported so that it’s impossible to catch and handle via 'Typeable'.
newtype ErrorException = ErrorException Error

-- | Show the pretty printed string without quotes.
instance Show ErrorException where
  showsPrec i (ErrorException err) = showString (err & prettyError & Text.unpack)
instance Exception ErrorException where
  displayException = show

-- | Like 'unwrapError', but instead of using 'error', it will 'Exc.throwIO' the pretty-printed error.
--
-- The advantage over `unwrapError` is that it crashes immediately, and not just when the 'Either' is forced,
-- leading to a deterministic immediate abortion of your IO code
-- (<https://github.com/ghc-proposals/ghc-proposals/pull/330 but no stack trace can be produced at the moment!>).
--
-- __Throws opaque Exception:__ if Error
--
-- Example:
--
-- >>> unwrapIOError $ Left (newError "oh no!")
-- oh no!
--
-- Important: 'Error' itself does /not/ implement 'Exception' to discourage the exception workflow.
-- The 'Exception' thrown is private to this module and thus can’t be “caught” in a typed manner.
-- If you use this function, you either have to catch 'Exc.SomeException', or it will bubble up and lead to
-- your program crashing.
unwrapIOError :: Either Error a -> IO a
unwrapIOError = \case
  Left err -> Exc.throwIO $ ErrorException err
  Right a -> pure a

-- | Like 'expectError', but instead of using 'error', it will 'Exc.throwIO' the pretty-printed error.
--
-- The advantage over `expectError` is that it crashes immediately, and not just when the 'Either' is forced,
-- leading to a deterministic immediate abortion of your IO code
-- (<https://github.com/ghc-proposals/ghc-proposals/pull/330 but no stack trace can be produced at the moment!>).
--
--
-- __Throws opaque Exception:__ if Error
--
-- Example:
--
-- >>> expectIOError "something bad happened" $ Left (newError "oh no!")
-- something bad happened: oh no!
--
-- Important: 'Error' itself does /not/ implement 'Exception' to discourage the exception workflow.
-- The 'Exception' thrown is private to this module and thus can’t be “caught” in a typed manner.
-- If you use this function, you either have to catch 'Exc.SomeException', or it will bubble up and lead to
-- your program crashing.
expectIOError :: Text -> Either Error a -> IO a
expectIOError context = \case
  Left err -> Exc.throwIO $ ErrorException (addContext context err)
  Right a -> pure a

-- | Catch any 'Exc.IOException's thrown by an @IO a@ as @Either Error a@.
--
-- The IOException is converted to an error with 'exceptionToError', and the given message
-- is added with 'addContext'. This prevents the common pattern of bubbling up exceptions
-- without any context.
--
-- >>> ifIOError "could not open file" (Control.Exception.throwIO (userError "oh noes!"))
-- Left (Error ["could not open file","user error (oh noes!)"])
--
-- It can then be handled like a normal 'Error'.
--
-- The function lends itself to piping with '(&)':
--
-- >>> Control.Exception.throwIO (userError "oh noes!") & ifIOError "could not open file"
-- Left (Error ["could not open file","user error (oh noes!)"])
--
-- and if you just want to annotate the error and directly throw it again:
--
-- >>> Control.Exception.throwIO (userError "oh noes!") & ifIOError "could not open file" >>= unwrapIOError
-- could not open file: user error (oh noes!)
ifIOError :: Text -> IO a -> IO (Either Error a)
ifIOError = ifError @Exc.IOException

-- | Catch any 'Exc.Exception's thrown by an @IO a@ as @Either Error a@.
--
-- The IOException is converted to an error with 'exceptionToError', and the given message
-- is added with 'addContext'. This prevents the common pattern of bubbling up exceptions
-- without any context.
--
-- Use @TypeApplications@ to specify the 'Exception' you want to catch.
--
-- >>> ifError @Exc.ArithException "arithmetic exception" (putStr $ show $ 1 Data.Ratio.% 0)
-- Left (Error ["arithmetic exception","Ratio has zero denominator"])
--
-- It can then be handled like a normal 'Error'.
--
-- The function lends itself to piping with '(&)':
--
-- >>> (putStr $ show $ 1 Data.Ratio.% 0) & ifError @Exc.ArithException "arithmetic exception"
-- Left (Error ["arithmetic exception","Ratio has zero denominator"])
--
-- Bear in mind that pure exceptions are only raised when the resulting code is forced
-- (thus the @putStrLn $ show@ in the above example).
ifError :: forall exc a. (Exception exc) => Text -> IO a -> IO (Either Error a)
ifError context io = Exc.try @exc io <&> first (addContext context . exceptionToError)