4 ms·
Could you expand on your issue with exceptions? In this article I'm using the distinction between exceptions and errors from https://wiki.haskell.org/Error_vs._
by kpmah 11y ago
Could you expand on your issue with exceptions? In this article I'm using the distinction between exceptions and errors from https://wiki.haskell.org/Error_vs._Exception https://wiki.haskell.org/Error_vs._Exception
You're right about the bottom input. I'll add it to the article.
- tazjin 11y agoPure code can (unfortunately) throw exceptions, e.g.: Prelude> head [] *** Exception: Prelude.head: empty list
- cballard 11y agoSeems like a bug, shouldn't that return a Maybe? (the equivalent in Swift returns an Optional)
- dack 11y agoThere are libraries that reimplement these types of functions using Maybes for the reason you would guess. I think it's mostly a historical artifact at this point.
- chadaustin 11y agoThere is a Haskell function called headMay [1] that returns a Maybe, but the Prelude head function throws when given an empty list. Either way, pure code can throw exceptions in Haskell. Consider division by zero for example. [1] https://hackage.haskell.org/package/safe-0.3.9/docs/Safe.html https://hackage.haskell.org/package/safe-0.3.9/docs/Safe.htm...
- dllthomas 11y agoYeah, many (myself included) share the view that it's a wart in the Haskell standard lib. There are good alternatives to using that function, though (same for most of the other unfortunately partial functions).
- dllthomas 11y agoIf you look at the type of `error`, `assert`, or `undefined` (or `throw`, also defined in Control.Exception) you'll see that they actually don't show up in the type: Prelude> :t error error :: [Char] -> a Prelude> :t undefined undefined :: t Prelude> :t assert assert :: Bool -> a -> a Prelude Control.Exception> :t throw throw :: Exception e => e -> a This means you can throw from anywhere. You can only catch in IO.
- kpmah 11y agoIn the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. I wasn't aware of 'throw' and that certainly weakens my argument. You could maybe argue it is an escape hatch in the same vein as unsafePerformIO, but I don't know how it is viewed by the community. You could argue I'm playing word games here, and I have some sympathy for that argument. What I wanted to get across is checked exceptions ala. Java (although they are too commonly bypassed in that example). Maybe moving it to the documentation section is a good compromise.
- dllthomas 11y ago> In the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. Okay, but in the case of GHC you actually can recover from them. > I wasn't aware of 'throw' and that certainly weakens my argument. You could maybe argue it is an escape hatch in the same vein as unsafePerformIO, but I don't know how it is viewed by the community. Asynchronous exceptions are pretty widely accepted as the way to interrupt a long-running pure computation. `error` is pretty widely used on identifying programming errors and pretty well reserved to that case. There is some dispute over whether exceptions or Either is more appropriate to dealing with exceptional conditions in IO; more reluctance around exceptions for reporting exceptional conditions outside of IO (partly because of the "only catch in IO" restriction, and substantially because we have other, good methods). > What I wanted to get across is checked exceptions ala. Java (although they are too commonly bypassed in that example). I'd like to see some language flesh out checked exceptions with parametric polymorphism. Alack, this is not what Haskell has (yet?) done.