Newest at the top
| 2025-12-27 20:30:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 20:27:19 +0100 | <pie_> | <geenvoud> pie_: that'll be a certain westley weimer https://dl.acm.org/doi/10.1145/1330017.1330019 |
| 2025-12-27 20:25:22 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-12-27 20:22:00 +0100 | <pie_> | i dont suppose anyone knows who this is https://www.youtube.com/watch?v=NfXt_Eb0ZU8 |
| 2025-12-27 20:18:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 20:14:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 20:06:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 20:00:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:59:04 +0100 | lockna_ | (~lockna@193-81-168-132.hdsl.highway.telekom.at) (Remote host closed the connection) |
| 2025-12-27 19:49:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 19:49:07 +0100 | araujo | (~araujo@216.73.163.51) (Quit: araujo) |
| 2025-12-27 19:44:46 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-12-27 19:44:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:41:11 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-12-27 19:39:53 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2025-12-27 19:38:25 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 264 seconds) |
| 2025-12-27 19:37:25 +0100 | comonad | (~comonad@p200300d02720e400847046dc37dbdd66.dip0.t-ipconnect.de) (Quit: WeeChat 4.7.0-dev) |
| 2025-12-27 19:36:28 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-27 19:34:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-27 19:29:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:24:40 +0100 | <sm> | it is the best exemplar of the "monitor subsystems and restart them when they fail" strategy |
| 2025-12-27 19:22:27 +0100 | <sm> | also, Erlang is an excellent thing to read about |
| 2025-12-27 19:22:11 +0100 | <sm> | pie_ , you're on the right track - it's good to think about the kinds of errors and how you want to handle each; there are multiple error handling strategies. |
| 2025-12-27 19:21:57 +0100 | <pie_> | im too dumb to reinvent the wheel, thats why im asking :> |
| 2025-12-27 19:21:41 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2025-12-27 19:20:54 +0100 | <monochrom> | Alterantively use Haskell's STM. :) |
| 2025-12-27 19:19:50 +0100 | <monochrom> | Easier said than done, sure. That's why you outsource it to a mature relational database, rather than bothering to code up your own. |
| 2025-12-27 19:18:41 +0100 | <monochrom> | That would be when an error in the middle of something causes invalid states. The solution is to undo that unfinished something. |
| 2025-12-27 19:18:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-27 19:18:07 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-27 19:17:03 +0100 | <monochrom> | Another scenerio is much more complex but also a solved problem so you should not re-invent the wheel. Relational databases, transactions, and the choice to rollback a transaction (because you detect an invalidity). |
| 2025-12-27 19:14:46 +0100 | <pie_> | but i guess i was implicitly also thinking about things like services |
| 2025-12-27 19:14:37 +0100 | <pie_> | makes sense |
| 2025-12-27 19:14:30 +0100 | <pie_> | and ok for cli applications |
| 2025-12-27 19:14:20 +0100 | <pie_> | like yes ive seen gui applications that pop up an exception window (for stuff thats not the failure to open a file) and let you try to continue anyway |
| 2025-12-27 19:13:53 +0100 | <pie_> | but if you explain it that way, sure |
| 2025-12-27 19:13:47 +0100 | <pie_> | well, its not so obvious to my puny brain |
| 2025-12-27 19:13:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:12:07 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-27 19:11:54 +0100 | <monochrom> | But taking a step back, those are just logical conclusions of the respective specifications. The first case has already required non-interactiveness, so you can only give up. The second case has already specified a GUI, implying that you never exit unless the user tells you to. It is common sense, there is no need to read a book about it. |
| 2025-12-27 19:11:18 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:694d:f25a:3b3c:f3f9) synchromesh |
| 2025-12-27 19:10:56 +0100 | <pie_> | even make sense?" - something like that |
| 2025-12-27 19:10:56 +0100 | <pie_> | the short of the video is that safe systems from a language designer POV are about removing undefined behavior from a language, from a practitioner viewpoint are about determinism, and error handling is about moving the application from an unintended state back to an intended state, and the question is (well not the way im phrasing it) that the overlap between understood state and error state is so small or nonexistent enough that "does error handling |
| 2025-12-27 19:10:07 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:694d:f25a:3b3c:f3f9) (Read error: Connection reset by peer) |
| 2025-12-27 19:09:14 +0100 | <monochrom> | The scenerio I'm most familiar with is that the user gives you a filename and you open it to do your job. We anticipate that sometimes the open attempt fails. For a non-interactive command line program, you pretty have no choice but give up and exit. For a GUI though, you can and should always catch the exception, tell the user, and be ready to take another filename and try again. |
| 2025-12-27 19:08:47 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-27 19:06:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-27 19:05:31 +0100 | <pie_> | watched most of this (2x) and i also largely agree with the question being asked, but it doesnt really provide much in terms of solutions i think. https://www.youtube.com/watch?v=ZUAPHTbxnAc The Absurdity of Error Handling: Finding a Purpose for Errors in Safety-Critical SYCL - Erik Tomusk |
| 2025-12-27 19:01:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:51:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |