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.

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?

    > 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).