purescript / purescript-exceptions Goto Github PK

Could we add a try operator like Control.Exception has in Haskell? I'm currently using this:

try ∷ ∀ a e. Eff (err ∷ EXCEPTION | e) a → Eff e (Either Error a)
try action = catchException (pure ∘ Left) (Right <$> action)

The only problem would be that this introduces a dependency on purescript-either.

Currently, there is an accessor for Error.name (name :: Error -> String). It would be nice to have a helper that allows to create an error with a given name, like namedError :: String -> String -> Error.

Sometime you need to differentiate Error thrown by your code, and catch only Error you want. The most common use case is when you want to throw Error in Aff, and catch it, but other code might don't want to catch all Error.

Possible Solution

Define a class SomeError or any good name for this purpose, usually these methods will be defined with help of FFI code. But we can provides utility functions here.

class Show e <= SomeError e where
  toError :: e -> Error
  fromError :: Error -> Maybe e

While working on purescript-batteries, I ran into a collision between Control.Monad.Eff.Exception.error and Control.Monad.Eff.Console.error. I think people are more likely to mean Console.error than Exception.error when they just say error.

I'm not sure what else I would call it, though. Maybe toError? Or perhaps there could be a throw :: String -> Eff (err :: EXCEPTION | e) a function, which would sidestep error and throwException.

Obviously this isn't a problem with this package per se. I could (and may) address this in purescript-batteries. But I wanted to open an issue here for discussion.

This means that types don't unify if you use Eff (exception :: EXCEPTION | e) a in your own type signature and use eg. throw.

Is there a reason for this, other than length? It seems inconsistent with every other effect row name.

It is very misleading, and often a lie in the presence of asynchronicity. There are no clear semantics as to what it means to actually eliminate the effect (vs. purescript-run). I think it's better to just introduce the effect on both catchException and throwException. So you can't say "all exceptions are caught", you can only say "we are using the exception system provided by the host".

It seems clear that this package is intended to catch Error exceptions. However, catchException does this:

try {
        return t();
      } catch (e) {
        if (e instanceof Error || Object.prototype.toString.call(e) === "[object Error]") {
          return c(e)();
        } else {
          return c(new Error(e.toString()))();
        }
}

That is, if the exception is determined to not be an Error exception, it attempts to convert the exception to an Error exception. This conversion itself throws for both null and undefined, which are possible values. Furthermore, this implementation prevents users from catching other types of exceptions in an obvious way (they would have to use a different catch before this one).

Suggestion: just rethrow the exception if it is not Error.

ie, stack :: Error -> String, that just reads the stack property. There's no agreed-upon format but according to MDN all modern browsers support it, and I'm pretty sure it's always a String.

Hi,

I've been looking at https://nodejs.org/api/errors.html#errors_error_code recently, and I was wondering if this function should be added or should we have a separate package Purescript package for node's error module.