Oskar Hahn (Feb 06 2025 at 07:37): Oskar Hahn (Feb 06 2025 at 07:37):I don't like the way, the current version of Roc handles panics. Maybe this is something you could rethink with the new compiler.
The current way is, that the platform has to implement roc_panic. It can return some message to the user and then exit the process. This works nice for a use case like basic-cli. But it is problematic for a webserver, that should continue, even if there is one problematic request. I think, it is also a problem, when Roc is used as a plugin language. I don't think a plugin should be able to kill a process, by writing something like 5 / 0.
The current solutions is, that the platform has to use something like libunwind or longjmp to handle the panic. This is difficult and error prone for a platform author. I am not sure, if it is even possible to do in all possible host-languages. For example, I don't know how to do it in Go.
My question is, if the handling of panics could be done on the Roc-side and if a panic happens, an error is returned to the platform as a value.
This would require Roc to generate panic-handling in all functions, that are exported to the host. The generated functions like roc__ForHost_1_exposed_generic would return an value, that tells the platform, if an error happens.
I requested something similar here. I hope its ok that I push this topic with a more general angle.
Richard Feldman (Feb 06 2025 at 15:52):eventually I think it would be great if we got to a point where whenever the host calls a Roc function, it gets back a Result that's an Err if the call crashed, and the call automatically did all refcount decrements necessary on the way out
Richard Feldman (Feb 06 2025 at 15:53):however, doing this efficiently basically requires doing C++ exceptions, and when Folkert and I had that system implemented in 2019 or 2020, we hit so many problems with it that we ended up replacing it with the current system just because we could actually get it to work right
Richard Feldman (Feb 06 2025 at 15:54):so I think it's the nicest goal to aim for eventually, but I think there's a separate question of whether right now is the best time to try it again, or whether we should revisit it sometime after 0.1.0
Richard Feldman (Feb 06 2025 at 15:56):if anyone wants to explore it now, I'm open to that, but I want to start with the caution that we went down this road before and reverted it because we couldn't get it to work correctly :sweat_smile:
Brendan Hansknecht (Feb 06 2025 at 16:32):I definitely want to make sure the new llvm backend has lots of debug info. I might look into adding eh frames and dwarf frame info as well, but I'm guess I will find it overly complex and punt it
Brendan Hansknecht (Feb 06 2025 at 16:33):If we don't have full exception unwinding that cleans up state, I don't think this is worth having at all and we should leave it to the platform to setjmp longjmp if they want to.
Brendan Hansknecht (Feb 06 2025 at 16:34):I do think that long term having opt in for this would be great. I assume any platform that just wants to crash or uses an arena for allocation won't ever want this.
Richard Feldman (Feb 06 2025 at 16:45):that's fair too
Last updated: Jul 06 2025 at 12:14 UTC