Newest at the top
2024-10-25 20:33:06 +0200 | <lxsameer> | EvanR: tomsmeding mauke thanks for the help folks |
2024-10-25 20:32:51 +0200 | <lxsameer> | tomsmeding: cheers |
2024-10-25 20:32:41 +0200 | <tomsmeding> | (read the haddocks) |
2024-10-25 20:32:40 +0200 | <lxsameer> | tomsmeding: yes |
2024-10-25 20:32:34 +0200 | <tomsmeding> | Control.Exception.catch |
2024-10-25 20:32:19 +0200 | <tomsmeding> | no need to have another field for this in the record, as far as I can see |
2024-10-25 20:32:14 +0200 | scaniatrucker | (~user@78.56.98.5) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
2024-10-25 20:32:10 +0200 | <tomsmeding> | inside the implementation of the DB methods |
2024-10-25 20:32:02 +0200 | <tomsmeding> | lxsameer: okay; then "will handle any uncaught error using an error handler" is just something that it can do, right? |
2024-10-25 20:31:37 +0200 | <lxsameer> | tomsmeding: it is any code that implement the methods of the DB type |
2024-10-25 20:31:22 +0200 | <tomsmeding> | mauke: good point! |
2024-10-25 20:31:14 +0200 | <tomsmeding> | because then, can't it "just" catch them? |
2024-10-25 20:31:02 +0200 | <tomsmeding> | lxsameer: what is a "backend"? Is that one of the functions in that DB record? |
2024-10-25 20:30:40 +0200 | <mauke> | because SomeException is also an instance of Exception, so if your e is already SomeException, you might accidentally double-wrap it |
2024-10-25 20:30:16 +0200 | <lxsameer> | tomsmeding: the backend will throw them. and in my head the backend will handle any uncaught error using a error handler and re-throw those that it doesn't know about |
2024-10-25 20:30:15 +0200 | morsinichi | (~morsinich@61.4.97.157) (Remote host closed the connection) |
2024-10-25 20:30:10 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
2024-10-25 20:30:05 +0200 | <mauke> | using the SomeException data constructor directly is probably a mistake in general. toException is the way to go |
2024-10-25 20:29:30 +0200 | <tomsmeding> | agree |
2024-10-25 20:29:23 +0200 | <EvanR> | letting someone catch it if they want |
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 |