Newest at the top
| 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) |
| 2025-12-27 18:46:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:38:17 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-12-27 18:37:55 +0100 | wennefer0_______ | (~wennefer0@user/wennefer0) (Ping timeout: 240 seconds) |
| 2025-12-27 18:35:25 +0100 | <pie_> | *design out all the errors its designed to handle, fall back to remote external intervention for whatever else |
| 2025-12-27 18:34:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 18:34:54 +0100 | <pie_> | just remove all the errors? :P |
| 2025-12-27 18:34:47 +0100 | <pie_> | idk, what do they do in embedded space software or whatever |
| 2025-12-27 18:34:34 +0100 | <pie_> | i wouldnt mind if i could read up on a thorough discussion of these kinds of things |
| 2025-12-27 18:34:18 +0100 | <pie_> | what if i dont want my programs to crash? (put a restarting wrapper around it? - so like presumably whatever erlang does i guess?) |
| 2025-12-27 18:33:49 +0100 | wennefer0_______ | (~wennefer0@user/wennefer0) wennefer0 |
| 2025-12-27 18:31:52 +0100 | <pie_> | ok sure i guess some of the stuff you would start with is the difference between invalid programs, and runtime errors / that you want to fail fast to prevent invalid state propagation, .. |
| 2025-12-27 18:31:40 +0100 | <monochrom> | In many cases, there is a reasonable plan B. The details depends on the actual code and/or the actual specification. |
| 2025-12-27 18:30:52 +0100 | <pie_> | so like, what does "good error handling design" look like in software engineering? |
| 2025-12-27 18:30:32 +0100 | <pie_> | (alternatively, what do i read on this) |
| 2025-12-27 18:30:32 +0100 | <pie_> | but like how do you do stuff properly if you dont want your programs to just fail |
| 2025-12-27 18:30:32 +0100 | <pie_> | ok maybe today if i thought about it i could do a little better; just crash the program if you run into an issue (which is what happens when you dont catch an exception i guess) |
| 2025-12-27 18:30:32 +0100 | <pie_> | beyond the equivalent of catching an error and doing nothing with it or putting a todo there or something |
| 2025-12-27 18:30:32 +0100 | <pie_> | this is really basic but i never understood how to do error handling in software properly |
| 2025-12-27 18:30:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:29:50 +0100 | <haskellbridge> | <Liamzee> life is fun, now i'm deliberately trying to vibecode segfaults on a Apple Silicon Mac |
| 2025-12-27 18:21:09 +0100 | annamalai | (~annamalai@157.32.142.174) annamalai |
| 2025-12-27 18:20:50 +0100 | annamalai | (~annamalai@157.32.142.174) (Remote host closed the connection) |
| 2025-12-27 18:20:00 +0100 | annamalai | (~annamalai@157.32.142.174) annamalai |
| 2025-12-27 18:18:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-12-27 18:12:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:11:16 +0100 | Everything | (~Everythin@172-232-54-192.ip.linodeusercontent.com) Everything |
| 2025-12-27 18:03:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 17:58:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 17:58:03 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 260 seconds) |
| 2025-12-27 17:57:06 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
| 2025-12-27 17:50:20 +0100 | annamalai | (~annamalai@157.32.132.241) (Ping timeout: 245 seconds) |