Hi, Thanks to everybody who replied. I see another solution: are there any hidden problems? I found an interesting package, ChasingBottoms which contains a function testing a value to be bottom and returning a Boolean (of course it cannot be done without unsafePerformIO). I borrowed the idea from that package, and wrote two functions: unThrow :: (Exception e) => a -> Either e a unThrow a = unsafePerformIO $ (E.evaluate a >>= return . Right) `E.catch` (\e -> return $ Left e) -- or perhaps the right argument of catch could be just (return . Left)? bm2mb :: a -> Maybe a bm2mb a = case unThrow a of Left (e::SomeException) -> Nothing Right a -> Just a So, if there is a value inside the lazy list which is a bottom (binary parse failure of the last received object in this case, catching any possible exception) then the value can be converted to Nothing within pure code, and then excluded from the result using catMaybes. This solution seems to be working for me. PS Maybe the way I am using the serialized data needs to be changed by implementing some kind of an iterator over the binary stream, and then by taking one object at a time and consuming it right there the problem might be eliminated entirely... Thanks again. -- Dimitry Golubovsky Anywhere on the Web

On 07.09.2010 20:51, Henning Thielemann wrote:

This solution looks very ugly to me. Catching 'error's is debugging, but parser failure is kind of exception handling. I guess, the errors you want to catch are caused by non-supported fail method, right? Can't you use a monad transformer like explicit-exception:Synchronous.Exception or transformers:ErrorT around the Binary parser?

ErrorT is useless here since it cannot intercept calls to 'error'. Same should be the case with ExcepcionalT. There is also performance penalty

Quoth Dimitry Golubovsky ,

I see another solution: are there any hidden problems?

I found an interesting package, ChasingBottoms which contains a function testing a value to be bottom and returning a Boolean (of course it cannot be done without unsafePerformIO).

I borrowed the idea from that package, and wrote two functions:

unThrow :: (Exception e) => a -> Either e a

unThrow a = unsafePerformIO $ (E.evaluate a >>= return . Right) `E.catch` (\e -> return $ Left e)

Like Henning, I'm not going to try to predict a specific problem with it, but I don't like it. Have you had a chance to look at cereal (Data.Serialize)? I frankly couldn't make it do what you need, as written, but I could make it work if I modify Serialize.Get to export "Get(..)" instead of "Get".

From there I wrote a variant of the Get (>>=) function with an additional end-value-on-failure parameter, [] in your program:

ebind m g e = Get (\ s0 f k -> unGet m s0 (\ _ _ -> k B.empty e) (\ s a -> unGet (g a) s f k)) ... so to get your error bounded array of Int, getx = ebind get (\ a -> getx >>= return . (:) a) [] I think it's very likely there's a simpler way to do this with Data.Serial as written, I am just a little backwards with state monads and that kind of thing. Donn Cave, donn@avvanta.com

On Tue, Sep 7, 2010 at 2:45 PM, Dimitry Golubovsky wrote:

unThrow a = unsafePerformIO $ (E.evaluate a >>= return . Right) `E.catch`                                               (\e -> return $ Left e)

-- or perhaps the right argument of catch could be just (return . Left)?

bm2mb :: a -> Maybe a

bm2mb a = case unThrow a of   Left (e::SomeException) -> Nothing   Right a -> Just a

Philosophically these functions are Nasty because they violate referential transparency. In particular it's possible for the same expression to throw different exceptions each time it's run depending on how it's optimised, what other threads are doing, if the user presses ctrl-C, etc. etc. See the spoon package: http://hackage.haskell.org/package/spoon which alleviates this a little by only catching some kinds of exception, and not telling you which it caught. It still violates monotonicity (I believe), so purists will be upset, but practically it can be useful for when editing the source code to provide explicit exceptions (which is ideally what you'd do) is not an option.

donn:

Quoth Dimitry Golubovsky ,

...

Is there any way to catch/detect failures inside the Get monad? It is not an instance of MonadError, so catchError does not work.

Ideally, the function would keep decoding as long as it is possible, and upon the first failure of the parser, return whatever has been decoded.

I believe it can't be done. (I've seen three responses that seemed to be proposing some course of action, but ... correct me if I'm wrong, nothing that would allow you to use Get in Data.Binary this way.)

The key point is the use of `throw', via `error', in Get's `fail'. `throw' raises an exception that can be caught only in IO, so you can't catch it inside Get. So ... while `fail' is a Monad function, it isn't implemented here in a way you could use, like it is in Maybe for example. Nor could it be, I think, which is kind of unfortunate.

For strict, checked binary parsing, use the cereal package. For lazy binary parsing with async errors, use binary. They're the main two points in the design space. The other is to tag the lazy stream, and insert failure tags in the structure. -- Don