[Haskell-cafe] Taking Exception to Exceptions

[Henning Thielemann]

Immanuel Litzroth schrieb:

> Anyway, there is one more problem I have related to exceptions that is
> about forcing strictness. It relates to option parsing. I have an option -t
> that says which track from a file of tracks to print. So I go
> 
> data Flags = TrackNumber !Int deriving(Read, Show, Eq)
> 
> makeTrackNumber :: String -> Flags
> makeTrackNumber str =
>     TrackNumber $ read str
> 
> options = [GetOpt.Option ['t'] ["tracknumber"] (GetOpt.ReqArg
> makeTrackNumber "tracknumber") "number of track to show"]
> 
> Now my main goes
> main = do
>   args <- getArgs
>   opts <- evaluate $ GetOpt.getOpt GetOpt.RequireOrder options args
>   print "done getting the opts"
>   case opts of ...
> 
> which of course first prints "done getting opts" and then throws an
> exception if I give it a flag
> -t abc.

'evaluate' is strange here. Is it ok to put the print after the case ?
But I have probably still not understood the problem.

Let me point to two other issues:
  An elegant way to use GetOpt is:

http://www.haskell.org/haskellwiki/High-level_option_handling_with_GetOpt

  I find it bad style to hide the exceptions, that can be raised. The
type of an action should reflect what exceptions are to be expected. You
can achieve this with Control.Monad.Exception.Synchronous from

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exception
   or Control.Monad.Error from
    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/transformers

For an application, using these techniques, see:
   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/equal-files