Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Adapting Error to Except

Now that Control.Monad.Error is deprecated, and Control.Monad.Except reigns supreme, a lot of sources online haven't caught up, and still show examples of how to use Error.

So how would I go about turning

instance Error MyError where
  noMsg  = ...
  strMsg = ...

into something using Except. Just replacing Error with Except didn't work as Except expects additional type parameters

I understand that those exact methods don't exist in Except, so what's the alternative?

like image 431
Electric Coffee Avatar asked Jul 04 '15 13:07

Electric Coffee


People also ask

How do you use except value error?

Here is a simple example to handle ValueError exception using try-except block. import math x = int(input('Please enter a positive number:\n')) try: print(f'Square Root of {x} is {math. sqrt(x)}') except ValueError as ve: print(f'You entered {x}, which is not a positive number. ')

Which type of error can be noticed and handled using try-except?

Raising and Catching Errors. The try/except control structure provides a way to process a run-time error and continue on with program execution.

What are the types of errors in exception handling?

There are three types of errors in programming: (a) Syntax Errors, (b) Runtime Errors, and (c) Logical Errors.

What is the best method for error handling?

Favour exceptions over error codes the current best practice for handling errors is to throw exceptions, rather than returning error codes (not necessarily an error code, but a type representing an error).


1 Answers

Short answer is: Replace Error by nothing at all, replace ErrorT by ExceptT, and things should continue to work as long as you don't use Errors methods, fail (which now has a different definition), or failing pattern matches in do notation.

The essential difference between the old Control.Monad.Error system and the new Control.Monad.Except system is that the new system imposes no class restriction on the error/exception type.

It was found that the ability to use any error/exception type at all, polymorphically, was more useful than the somewhat hacky ability to customize conversion of string error messages.

So the class Error has simply disappeared.

As a side effect, fail for ExceptT now is lifted from the underlying monad. This also changes the effect of failing patterns in do notation.

The old definition was:

fail msg = ErrorT $ return (Left (strMsg msg))

which I think is equivalent to

fail msg = throwError (strMsg msg)

If you still need this behavior, you can instead use

throwError yourIntendedErrorValue

(throwE works instead if you're using transformers (i.e. Control.Monad.Trans.Except) rather than mtl.)

The old do pattern matching failure would apply to things like

do
    Just x <- myErrorTAction
    ...

when the action actually returns Nothing. This is more awkward, but you could e.g. replace it with an explicit case match (essentially desugaring it):

do
    y <- myErrorTAction
    case y of
        Nothing -> throwE ...
        Just x -> do
           ...

@DanielWagner suggests the following to avoid extra indentation:

do
    x <- myErrorTAction >>= maybe (throwError ...) return
    ...

The removal of Error also eliminates the need for an inconsistency in naming that Control.Monad.Error had: Most transformers follow the rule that SomethingT is the name of the transformer, and Something is a type alias for SomethingT ... Identity. The old ErrorT broke that because the Error class was used for something entirely different.

In the new system, Except e = ExceptT e Identity, like for other transformers.

like image 171
Ørjan Johansen Avatar answered Sep 22 '22 14:09

Ørjan Johansen