Newest at the top
2024-10-25 20:28:59 +0200 | Igloo | (~ian@81.2.99.210) |
2024-10-25 20:28:49 +0200 | <EvanR> | by returning IO exception* |
2024-10-25 20:28:40 +0200 | <EvanR> | by returning IO actions in I/O code, you're kind of stepping outside a convention of..... just throwing the exception |
2024-10-25 20:28:37 +0200 | <tomsmeding> | and who would be handling them |
2024-10-25 20:28:31 +0200 | <tomsmeding> | who would be throwing those errors? |
2024-10-25 20:28:18 +0200 | <lxsameer> | so each backend provide a way to deal with it's specific error types? |
2024-10-25 20:27:59 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-10-25 20:27:55 +0200 | <lxsameer> | would it make sense for that DB type to have a errorHandler method as well ? |
2024-10-25 20:27:42 +0200 | Igloo | (~ian@81.2.99.210) (Remote host closed the connection) |
2024-10-25 20:27:20 +0200 | <tomsmeding> | s/functions/IO actions/ |
2024-10-25 20:27:17 +0200 | <tomsmeding> | EvanR: fair point |
2024-10-25 20:27:10 +0200 | <lxsameer> | i see, coool. And one last question |
2024-10-25 20:27:10 +0200 | tomsmeding | thinks haskell should have had checked exceptions |
2024-10-25 20:27:08 +0200 | <EvanR> | functions don't throwIO, IO actions throwIO |
2024-10-25 20:26:56 +0200 | <tomsmeding> | unless you very carefully vet what you call |
2024-10-25 20:26:49 +0200 | <tomsmeding> | so even if you neatly _return_ an exception, you might still accidentally throw one |
2024-10-25 20:26:39 +0200 | Flerix | (Flerix@user/Flerix) (Quit: Leaving) |
2024-10-25 20:26:37 +0200 | <tomsmeding> | just be mindful that other functions that _you_ are calling might also throw IO exceptions, unbeknownst to you |
2024-10-25 20:26:13 +0200 | <tomsmeding> | lxsameer: right, throwIO is the usual way to throw exceptions in IO code; but if you want to return them for some reason, the best way would be toException (well found) |
2024-10-25 20:26:13 +0200 | <EvanR> | very bad |
2024-10-25 20:26:12 +0200 | <EvanR> | no good |
2024-10-25 20:26:07 +0200 | <EvanR> | awful, terrible |
2024-10-25 20:25:50 +0200 | <lambdabot> | Exception e => e -> a |
2024-10-25 20:25:49 +0200 | <EvanR> | :t throw |
2024-10-25 20:25:47 +0200 | <EvanR> | non-IO might also use throw |
2024-10-25 20:25:24 +0200 | <EvanR> | like they didn't put all the case analysis cases, or they did division by zero, or evaluated an infinite loop |
2024-10-25 20:25:23 +0200 | <lxsameer> | cool, so the first suggestion is throwIO and then the approach above, right |
2024-10-25 20:25:00 +0200 | <EvanR> | but still might for weird reasons |
2024-10-25 20:24:53 +0200 | <EvanR> | non-IO is ideally not failing |
2024-10-25 20:24:40 +0200 | <tomsmeding> | yes that's called toException |
2024-10-25 20:24:40 +0200 | <EvanR> | yeah IO is prone to failing |
2024-10-25 20:24:36 +0200 | <tomsmeding> | oh |
2024-10-25 20:24:26 +0200 | <tomsmeding> | yes |
2024-10-25 20:24:18 +0200 | <tomsmeding> | lxsameer: just write `return . Just . SomeException` |
2024-10-25 20:24:14 +0200 | <lxsameer> | EvanR: ah, so it's kinda in the IOs contract that it might throw Exception |
2024-10-25 20:24:13 +0200 | <EvanR> | thanks, clear as mud lol |
2024-10-25 20:24:05 +0200 | <yahb2> | SomeException ; :: (Exception e, ; GHC.Internal.Exception.Type.HasExceptionContext) => ; e -> SomeException |
2024-10-25 20:24:05 +0200 | <tomsmeding> | % :t SomeException |
2024-10-25 20:23:50 +0200 | <yahb2> | type SomeException :: * ; data SomeException ; = forall e. ; (Exception e, GHC.Internal.Exception.Type.HasExceptionContext) => ; SomeException e ; -- Defined in ‘GHC.Internal.Exception... |
2024-10-25 20:23:50 +0200 | <tomsmeding> | % :i SomeException |
2024-10-25 20:23:43 +0200 | <lxsameer> | tomsmeding: to whenLeft Nothing migrationResult (return . Just . toException) right? |
2024-10-25 20:23:27 +0200 | <lxsameer> | tomsmeding: ok, if I use SomeException. the I have to change the https://git.sr.ht/~lxsameer/Feynman/tree/master/item/src/Feynman/DB/Postgres.hs#L52 |
2024-10-25 20:23:20 +0200 | <tomsmeding> | because SomeException literally means "this is a thing that implements Exception, but I forgot what precise type it was" |
2024-10-25 20:23:11 +0200 | <EvanR> | actually evaluating any value may throw some exception, but not by using throwIO |
2024-10-25 20:22:52 +0200 | <tomsmeding> | lxsameer: I would recommend using SomeException |
2024-10-25 20:22:22 +0200 | <EvanR> | there's no "checked exceptions" |
2024-10-25 20:22:12 +0200 | <EvanR> | lxsameer, there's no indication. Any IO action when executed might throw an exception |
2024-10-25 20:22:08 +0200 | <tomsmeding> | lxsameer: as you can see here, with this DB type, if you project the 'init' field from a DB value, you get back an IO (Maybe e) for an e that _you can choose_ |
2024-10-25 20:21:44 +0200 | <tomsmeding> | lol |
2024-10-25 20:21:42 +0200 | <tomsmeding> | what I said previously about the field type was wrong |