On Wed, Feb 22, 2012 at 18:51, John Meacham wrote:

On Wed, Feb 22, 2012 at 3:05 PM, Evan Laforge wrote:

...

It's awkward and surprising how getEnv throws an exception when an env var is not set, since it's very common for env vars to be optional, and it's not convenient to catch exceptions in haskell (I have to look

For true IO exceptions, you should be using the Prelude.catch mechanism.

This still assumes that it's an exceptional condition that is being modeled. It is not; it is correctly modeled as a Maybe. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 2/23/12 4:07 AM, Jon Fairbairn wrote:

+1. And it’s always irritated me that read at EOF raises an exception. Files having ends is not exceptional! (This is partly addressed by iteratees, I imagine, but I haven’t found time to get my head round those yet.)

As John Lato mentioned, unix-bytestring gets around that (and a number of other ugly issues in the API). [1] http://hackage.haskell.org/package/unix-bytestring -- Live well, ~wren

Am 23.02.2012 01:07, schrieb Evan Laforge:

On Wed, Feb 22, 2012 at 3:51 PM, John Meacham wrote:

...

On Wed, Feb 22, 2012 at 3:05 PM, Evan Laforge wrote:

...

It's awkward and surprising how getEnv throws an exception when an env var is not set, since it's very common for env vars to be optional, and it's not convenient to catch exceptions in haskell (I have to look up Control.Exception every time, and then add LANGUAGE

For true IO exceptions, you should be using the Prelude.catch mechanism. It's the right thing to do and makes your program more portable as a bonus. It is quite unfortunate that IO exceptions became conflated with imprecise and dynamic exceptions and clash in their names. They really are different beasts alltogether.

Good point, I had forgotten about the Prelude catch. I think I can go remove a bunch of ScopedTypedVariables now.

This situation is particularly annoying since hlint (1.8.24) always says: ... Error: Use Control.Exception.catch Found: catch Why not: Control.Exception.catch Note: Prelude.catch does not catch most exceptions And now I learn that Prelude.catch is the right version for i.e. file IO (so I should probably switch off that hlint "Error"). Regarding the actual proposal, I fully agree. I always use a wrapper based on getEnvironment. getEnvSave :: a -- ^ default value -> String -- ^ name of environment variable -> (String -> Maybe a) -- ^ parse and check value -> IO a getEnvSave defValue envVar readFun = liftM (maybe defValue (fromMaybe defValue . readFun) . lookup envVar) getEnvironment Cheers Christian

The ghc exception situation is a bit messy, and I never have all the distinctions quite memorized, but it's also because I hardly ever have to deal with exceptions (of the "magical return value" variety, I use Either and Maybe all the time), unlike certain other languages. And that's a very good thing!

If I forget the rest about exceptions due to lack of use, I should at least remember that IO exceptions are different from, and better behaved than, the imprecise ones.

On 23 February 2012 01:07, Evan Laforge wrote:

Good point, I had forgotten about the Prelude catch.  I think I can go remove a bunch of ScopedTypedVariables now.

Note that Prelude.catch has been deprecated in favor of Control.Exception.catch. If you want to catch IOErrors you can either use ScopedTypedVariables or System.IO.Error.catchIOError. Bas

On 23/02/2012 21:05, John Meacham wrote:

On Thu, Feb 23, 2012 at 8:18 AM, Bas van Dijk wrote:

...

On 23 February 2012 01:07, Evan Laforge wrote:

...

Good point, I had forgotten about the Prelude catch. I think I can go remove a bunch of ScopedTypedVariables now.

Note that Prelude.catch has been deprecated in favor of Control.Exception.catch. If you want to catch IOErrors you can either use ScopedTypedVariables or System.IO.Error.catchIOError.

Control.Exception.catch is not in haskell 98 or haskell 2010. It also requires pulling in some heavy extensions and actually has fundamentally different behavior than Prelude.catch. We definitely should not consider it a replacement.

We should consider Control.Exception.catch a generalisation of Prelude.catch. Having both exist was confusing, which is why Prelude.catch was deprecated. It does have a direct replacement: System.IO.Error.catchIOError. catch by itself doesn't require heavy extensions, but it is a bit easier to use with pattern types signatures (which is only available with ScopedTypeVariables, but that's because we're too lazy to separate them.) The right getEnv is easily available as (tryIOError . getEnv). I don't disagree with this proposal though - I think we added getEnv at a time when we were feeling all gung-ho about exceptions, in retrospect this was a bad place to use them. Cheers, Simon