11 ms·

Am I the only person who thinks divbyzero shouldn't take down a whole process? And along those lines, how would you envision handling processes that panic, I p

Am I the only person who thinks divbyzero shouldn't take down a whole process? And along those lines, how would you envision handling processes that panic, I presume they don't send out Hail Mary messages to sibling processes? Does one process take down them all with the intent of restarting the lot (with an external watchdog?)

YorickPeterse 8y ago
A panic will take down the entire system, and print a stacktrace for the process that triggered the panic. I think this is a fundamental requirement, as it dramatically cuts back the amount of exceptions you have to handle. Runtime exceptions can't bubble up implicitly, and they can't be thrown at the top-level. This prevents an exception 15 call stacks deep taking down the entire system unexpectedly. I do agree that zero division errors are a bit of an odd case to deal with, as it's not unlikely for them to happen during runtime. Having said that, in the past 10 years of coding I have never seen code that handled zero division exceptions and didn't just straight up ignore them (something I don't want to promote). I believe Pony returns 0 for zero division errors. As crazy as this may be, I do somewhat understand their choice. I think integer divisions would be easier if there was something like NaN but for integers. > And along those lines, how would you envision handling processes that panic Several years into the future, I envision there is a way to somehow act upon them (e.g. logging them in Sentry or a similar service), but the system would still shut down after this has been completed. I however will not add a mechanism that allows you to just swallow a panic.
- cphoover 8y ago
  So even if a panic happens in a subprocess the parent is killed? Why not allow the parent to handle restarting of the child? Maybe I misunderstand.
  - YorickPeterse 8y ago
    Panics are not meant to be retried, as they are used exclusively for handling bugs. Examples include: division by zero, sending a message to an object that doesn't support it (if you manage to bypass the compiler), etc. Whenever these occur, your program is broken. Restarting a process in that case won't change anything, as it will run into the same problem again and again. Expected errors such as network timeouts will use exceptions, and these have to be explicitly handled. For example, if you try to open a file that you don't have access to, an exception is raised.
    - cphoover 8y ago
      So these are errors that should have been caught by the compiler but were not? I'm just thinking generally for production code you have a process supervisor daemon automatically restart when there are fatal errors (out-of memory errors for example). But in languages like erlang that support processes, one of the advantages is that you can support this mechanism through the process model. If I hit a divide by zero error in an edge-case branch of code, I will still want my process restarted no?
      - YorickPeterse 8y ago
        > So these are errors that should have been caught by the compiler but were not? Some of them yes, others no. For example, the compiler can't statically guarantee that there are no divisions by zero. > If I hit a divide by zero error in an edge-case branch of code, I will still want my process restarted no? Sure, and so Inko may at some point have a system for running "clean up" code of sorts, to report the error, etc. Actually restarting of things is something I prefer to have done by a system daemon, as there is no guarantee a program can continue after a panic (e.g. memory might be corrupted based on the nature of the panic).

YorickPeterse 8y ago

A panic will take down the entire system, and print a stacktrace for the process that triggered the panic. I think this is a fundamental requirement, as it dramatically cuts back the amount of exceptions you have to handle. Runtime exceptions can't bubble up implicitly, and they can't be thrown at the top-level. This prevents an exception 15 call stacks deep taking down the entire system unexpectedly. I do agree that zero division errors are a bit of an odd case to deal with, as it's not unlikely for them to happen during runtime. Having said that, in the past 10 years of coding I have never seen code that handled zero division exceptions and didn't just straight up ignore them (something I don't want to promote). I believe Pony returns 0 for zero division errors. As crazy as this may be, I do somewhat understand their choice. I think integer divisions would be easier if there was something like NaN but for integers. > And along those lines, how would you envision handling processes that panic Several years into the future, I envision there is a way to somehow act upon them (e.g. logging them in Sentry or a similar service), but the system would still shut down after this has been completed. I however will not add a mechanism that allows you to just swallow a panic.

cphoover 8y ago
So even if a panic happens in a subprocess the parent is killed? Why not allow the parent to handle restarting of the child? Maybe I misunderstand.
- YorickPeterse 8y ago
  Panics are not meant to be retried, as they are used exclusively for handling bugs. Examples include: division by zero, sending a message to an object that doesn't support it (if you manage to bypass the compiler), etc. Whenever these occur, your program is broken. Restarting a process in that case won't change anything, as it will run into the same problem again and again. Expected errors such as network timeouts will use exceptions, and these have to be explicitly handled. For example, if you try to open a file that you don't have access to, an exception is raised.
  - cphoover 8y ago
    So these are errors that should have been caught by the compiler but were not? I'm just thinking generally for production code you have a process supervisor daemon automatically restart when there are fatal errors (out-of memory errors for example). But in languages like erlang that support processes, one of the advantages is that you can support this mechanism through the process model. If I hit a divide by zero error in an edge-case branch of code, I will still want my process restarted no?
    - YorickPeterse 8y ago
      > So these are errors that should have been caught by the compiler but were not? Some of them yes, others no. For example, the compiler can't statically guarantee that there are no divisions by zero. > If I hit a divide by zero error in an edge-case branch of code, I will still want my process restarted no? Sure, and so Inko may at some point have a system for running "clean up" code of sorts, to report the error, etc. Actually restarting of things is something I prefer to have done by a system daemon, as there is no guarantee a program can continue after a panic (e.g. memory might be corrupted based on the nature of the panic).