4 ms·

Inko is an interesting language, though the handling for panics sounds disturbing. Based on the documentation, panics abort the whole program and are not recove

Inko is an interesting language, though the handling for panics sounds disturbing. Based on the documentation, panics abort the whole program and are not recoverable. Things like dividing by zero or accessing an index outside of the bounds of an array will panic. While these aren’t incredibly common, I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case. The language seems heavily inspired by Erlang, which is very resilient to programmer errors in comparison. In Erlang, the philosophy is to let a lightweight process crash and restart it when there is a problem. This doesn’t need to have any effect on other lightweight processes that are running.

nixpulvis 2y ago
That's why you have wrappers that return Result enumerations. There is an overhead to check if an operation is valid, pay for it if you need it. This is exactly how Rust works, for example.
- demurgos 2y ago
  Rust's panics are recoverable, so they're more like exceptions. This means that you may need to care about "unwind" safety and values in a potentially invalid state. It's the main reason for mutex poisoning and having to deal with it when locking. Overall, I'm not entirely sure if Rust would be better or not if panics were non-recoverable. PS: For completeness, there are flags to control the panic behavior; but you can't rely on them when writing a lib.
  - ryang2718 2y ago
    Unless a library developer decides to abort on panic in the `toml`, then i don’t believe you can unwind.
  - haberman 2y ago
    The Rust docs specifically discourage using panics as try/catch: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html > It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below. I think panics in Rust are intended to be unrecoverable, and catch_unwind is mainly intended to make the shutdown more orderly and possibly localized. Any data structure that paniced is probably in an unknown state that is not safe for further use.
    - brokencode 2y ago
      The situation in Rust seems to be a bit complicated. But I did find that panicking within a thread you spawn kills just that thread and not the whole program. And it seems that Tokio has the same behavior. https://github.com/tokio-rs/tokio/issues/2002#issuecomment-663886031 https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6... And web frameworks like Tower provide standard ways of handling panics and turning them into error responses. https://docs.rs/tower-http/latest/tower_http/catch_panic/index.html https://docs.rs/tower-http/latest/tower_http/catch_panic/ind... So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.
    - Too 2y ago
      https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html explains the philosophy and how they got there a bit further. Rust grew from a short-lived task concept, where panic of a task wouldn't be the end of the world, then it got used to write bigger applications instead and finer catch-concepts were needed.
    - J_Shelby_J 2y ago
      Catch unwind is useful when you have a dependency that for some reason panics and you can’t control it.
- brokencode 2y ago
  How is it knowing to panic if it isn’t checking? It seems like I am paying the cost of doing the checking either way, at least in terms of performance. So it should give me the ability to handle the error somehow. As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me. I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.
  - paulddraper 2y ago
    > killing the whole program due to a bug anywhere in any part of the code is very foreign to me. But getting the wrong answer due to a bug anywhere in any part of the code is not?
    - deleted 2y ago
      [deleted]
    - ludwik 2y ago
      Allowing you to catch and handle an exception is not the same as silently returning a wrong answer.
      - caspper69 2y ago
        It seems to me that exceptions have a bad rep. Complaints range from too slow to hidden control flow to just not liking them. I absolutely see the benefit in application code, otherwise you're error checking every function call. On the other hand, I completely understand not using such a mechanism in kernel and driver code. But Rust has decided against exceptions (which I actually believe were part of the original vision way back when, but please don't quote me), so now there's panics. Everything is a tradeoff at some level.
      - paulddraper 2y ago
        Yes, the wrong answer is terrifying
YorickPeterse 2y ago
Panics are meant to be used sparingly and as a last resort, and are meant to signal "this code is utterly broken, go fix it". Handling such errors at runtime (e.g. by restarting just a lightweight process) doesn't make much sense, as you'll keep running into the issue over and over again and possibly even end up ignoring it. For runtime error handling you'd use algebraic types such as Result and Option, similar to most functional languages and Rust. The reason we don't allow catching of panics (such as Rust allows) is because it can result in people more or less ignoring such errors (something I've seen happen far too often in past projects) and just retrying over and over again, achieving the same result every time. I'd much rather have the program crash and scream loudly, forcing developers to address the issue. Fortunately, the chances of you actually running into a panic at runtime should be pretty slim, so not being able to catch them shouldn't be much of an issue in practice.
- nicoburns 2y ago
  I feel like if that's your take, then things like array indexing or dividing by zero should never panic. Because running into those things at runtime is very hard to prevent (unless you have tooling for enforcing that statically?)
  - YorickPeterse 2y ago
    There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods: - Array.get/Array.get_mut for when you want to panic on an out-of-bounds index - Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index So for example: [10, 20, 30].get(0) => 10 [10, 20, 30].get(42) => panic [10, 20, 30].opt(0) => Option.Some(10) [10, 20, 30].opt(42) => Option.None This pattern is applied across the standard library where this makes sense, such that the developer can pick which option works best for their needs. There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).
paulddraper 2y ago
> I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case. Then you need an alternative. And that alternative is...messy. Do you have exceptions? Do you type them? Or do you have explicit return values? Is there syntax sugar? Etc, etc.
- brokencode 2y ago
  All error handling is messy in one way or another. I am personally a fan of the exceptions in C#. It’s good enough for me and doesn’t make me add a bunch of error types to all my methods. I also like the Erlang philosophy of letting the lightweight process crash as soon as any problem occurs and having a supervisor decide what to do.
BobaFloutist 2y ago
Ok so I'm a bit of a coding noob, but couldn't you hypothetically catch panics before they happen by having some boilerplate you insert in every case that could cause one? I guess checking to make sure you aren't dividing by zero before you divide every time or checking an index access against the bounds of an array could have some performance implications, and also it would be prohibitively hard to actually enforce it across your team?
- brokencode 2y ago
  Yup, that would be the fix. It is a logical error to even try to be dividing by zero, so your code should handle it. Regardless of whether there is a panic, this is what you'd want to do. But the problem is that people make mistakes or forget every once in a while, and as you get more people working on large programs, these mistakes happen more often. So you have to assume that it'll most likely happen in your production software sooner or later. Crashing the whole program is a fairly catastrophic outcome in my opinion, and should be reserved for only truly unrecoverable problems like hardware failures.
rurban 2y ago
And how do want to deal with fatal errors? Overflows and divide by zero are easily avoidable and should be fatal. Even the Apollo lander program aborted and even caused a reboot. Such that the reboot loop caused an uncontrollable lander, just by overloading the IO. The scheduler could have killed the radar process, but this was Aldrin's job, and he failed, not the scheduler.

nixpulvis 2y ago

That's why you have wrappers that return Result enumerations. There is an overhead to check if an operation is valid, pay for it if you need it. This is exactly how Rust works, for example.

demurgos 2y ago
Rust's panics are recoverable, so they're more like exceptions. This means that you may need to care about "unwind" safety and values in a potentially invalid state. It's the main reason for mutex poisoning and having to deal with it when locking. Overall, I'm not entirely sure if Rust would be better or not if panics were non-recoverable. PS: For completeness, there are flags to control the panic behavior; but you can't rely on them when writing a lib.
- ryang2718 2y ago
  Unless a library developer decides to abort on panic in the `toml`, then i don’t believe you can unwind.
- haberman 2y ago
  The Rust docs specifically discourage using panics as try/catch: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html > It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below. I think panics in Rust are intended to be unrecoverable, and catch_unwind is mainly intended to make the shutdown more orderly and possibly localized. Any data structure that paniced is probably in an unknown state that is not safe for further use.
  - brokencode 2y ago
    The situation in Rust seems to be a bit complicated. But I did find that panicking within a thread you spawn kills just that thread and not the whole program. And it seems that Tokio has the same behavior. https://github.com/tokio-rs/tokio/issues/2002#issuecomment-663886031 https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6... And web frameworks like Tower provide standard ways of handling panics and turning them into error responses. https://docs.rs/tower-http/latest/tower_http/catch_panic/index.html https://docs.rs/tower-http/latest/tower_http/catch_panic/ind... So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.
  - Too 2y ago
    https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html explains the philosophy and how they got there a bit further. Rust grew from a short-lived task concept, where panic of a task wouldn't be the end of the world, then it got used to write bigger applications instead and finer catch-concepts were needed.
  - J_Shelby_J 2y ago
    Catch unwind is useful when you have a dependency that for some reason panics and you can’t control it.
brokencode 2y ago
How is it knowing to panic if it isn’t checking? It seems like I am paying the cost of doing the checking either way, at least in terms of performance. So it should give me the ability to handle the error somehow. As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me. I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.
- paulddraper 2y ago
  > killing the whole program due to a bug anywhere in any part of the code is very foreign to me. But getting the wrong answer due to a bug anywhere in any part of the code is not?
  - deleted 2y ago
    [deleted]
  - ludwik 2y ago
    Allowing you to catch and handle an exception is not the same as silently returning a wrong answer.
    - caspper69 2y ago
      It seems to me that exceptions have a bad rep. Complaints range from too slow to hidden control flow to just not liking them. I absolutely see the benefit in application code, otherwise you're error checking every function call. On the other hand, I completely understand not using such a mechanism in kernel and driver code. But Rust has decided against exceptions (which I actually believe were part of the original vision way back when, but please don't quote me), so now there's panics. Everything is a tradeoff at some level.
    - paulddraper 2y ago
      Yes, the wrong answer is terrifying

YorickPeterse 2y ago

Panics are meant to be used sparingly and as a last resort, and are meant to signal "this code is utterly broken, go fix it". Handling such errors at runtime (e.g. by restarting just a lightweight process) doesn't make much sense, as you'll keep running into the issue over and over again and possibly even end up ignoring it. For runtime error handling you'd use algebraic types such as Result and Option, similar to most functional languages and Rust. The reason we don't allow catching of panics (such as Rust allows) is because it can result in people more or less ignoring such errors (something I've seen happen far too often in past projects) and just retrying over and over again, achieving the same result every time. I'd much rather have the program crash and scream loudly, forcing developers to address the issue. Fortunately, the chances of you actually running into a panic at runtime should be pretty slim, so not being able to catch them shouldn't be much of an issue in practice.

nicoburns 2y ago
I feel like if that's your take, then things like array indexing or dividing by zero should never panic. Because running into those things at runtime is very hard to prevent (unless you have tooling for enforcing that statically?)
- YorickPeterse 2y ago
  There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods: - Array.get/Array.get_mut for when you want to panic on an out-of-bounds index - Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index So for example: [10, 20, 30].get(0) => 10 [10, 20, 30].get(42) => panic [10, 20, 30].opt(0) => Option.Some(10) [10, 20, 30].opt(42) => Option.None This pattern is applied across the standard library where this makes sense, such that the developer can pick which option works best for their needs. There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).

paulddraper 2y ago

> I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case. Then you need an alternative. And that alternative is...messy. Do you have exceptions? Do you type them? Or do you have explicit return values? Is there syntax sugar? Etc, etc.

brokencode 2y ago
All error handling is messy in one way or another. I am personally a fan of the exceptions in C#. It’s good enough for me and doesn’t make me add a bunch of error types to all my methods. I also like the Erlang philosophy of letting the lightweight process crash as soon as any problem occurs and having a supervisor decide what to do.

BobaFloutist 2y ago

Ok so I'm a bit of a coding noob, but couldn't you hypothetically catch panics before they happen by having some boilerplate you insert in every case that could cause one? I guess checking to make sure you aren't dividing by zero before you divide every time or checking an index access against the bounds of an array could have some performance implications, and also it would be prohibitively hard to actually enforce it across your team?

brokencode 2y ago
Yup, that would be the fix. It is a logical error to even try to be dividing by zero, so your code should handle it. Regardless of whether there is a panic, this is what you'd want to do. But the problem is that people make mistakes or forget every once in a while, and as you get more people working on large programs, these mistakes happen more often. So you have to assume that it'll most likely happen in your production software sooner or later. Crashing the whole program is a fairly catastrophic outcome in my opinion, and should be reserved for only truly unrecoverable problems like hardware failures.

rurban 2y ago

And how do want to deal with fatal errors? Overflows and divide by zero are easily avoidable and should be fatal. Even the Apollo lander program aborted and even caused a reboot. Such that the reboot loop caused an uncontrollable lander, just by overloading the IO. The scheduler could have killed the radar process, but this was Aldrin's job, and he failed, not the scheduler.