Newest at the top
| 2024-10-25 20:35:44 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-25 20:35:35 +0200 | <EvanR> | where did the haskell exception system come from. Is it "original research" or based on a previous language's exception system |
| 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 |