Proposal: When possible, give more useful exceptions from rawSystem and friends

Evan Laforge qdunkan at gmail.com
Mon Apr 29 04:50:04 CEST 2013


I definitely support better errors for binary not found, I have always used
a wrapper that waits for the child and logs an error if it was not found,
but all it does is print a msg to stderr.

I still feel like we should learn from the latest python subprocess.py
module.  They have fixed a number of subtle bugs over many years and much
testing.  They also use pipes to communicate errors back to the parent.

That said, I'm in favor of this patch because it's still better than the
current situation.


On Sun, Apr 28, 2013 at 7:06 PM, Ian Lynagh <ian at well-typed.com> wrote:

>
> Hi all,
>
> Currently, if you try to use rawSystem to run a program that doesn't
> exist, you will just get a bad error code as a result, e.g. this
> program:
>
>     import System.IO.Error
>     import System.Process
>
>     main :: IO ()
>     main = do (rawSystem "/bin/true" [] >>= print)
>                 `catchIOError` \e -> putStrLn ("Exc: " ++ show e)
>               (rawSystem "/bin/false" [] >>= print)
>                 `catchIOError` \e -> putStrLn ("Exc: " ++ show e)
>               (rawSystem "/non/existent" [] >>= print)
>                 `catchIOError` \e -> putStrLn ("Exc: " ++ show e)
>               putStrLn "Done"
>
> prints:
>
>     ExitSuccess
>     ExitFailure 1
>     ExitFailure 127
>     Done
>
> However, if we are on a platform that supports vfork, then we can pass
> information from the child process back to the parent process as they
> share address space. With the attached patch we instead get:
>
>     ExitSuccess
>     ExitFailure 1
>     Exc: resolveProcessHandle: does not exist (No such file or directory)
>
> (and it should be easy to also get "/non/existent" in the exception).
>
>
> If there are platforms that don't support vfork, then they will still
> give the old output. I haven't yet looked at whether we can also get
> good exceptions on Windows (the patch won't build on Windows yet; I
> still need to update the Windows-specific code).
>
> I think that despite the possibility that some platforms may not be able
> to support it, we should provide the better behaviour on platforms that
> do.
>
> What do you think?
> And do you have any other comments on the patch?
>
> (this proposal was inspired by
> http://hackage.haskell.org/trac/ghc/ticket/7859).
>
>
> Suggested discussion deadline: Mon 13 May 2013.
>
>
> Thanks
> Ian
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130429/11b2a0f2/attachment-0001.htm>


More information about the Libraries mailing list