4 ms·

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 sh

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
- brokencode 2y ago
  Programs have all kinds of bugs for all kinds of reasons. That’s why you need unit testing, functional testing, performance testing, usability testing, accessibility testing, etc. Why single out just a few types of bugs to crash the whole program? Let me catch it and decide what to do. If it’s in a single request to my web server, I’d like that single request return an error code. I would not like all other concurrent requests for all other users to fail as well.

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
brokencode 2y ago
Programs have all kinds of bugs for all kinds of reasons. That’s why you need unit testing, functional testing, performance testing, usability testing, accessibility testing, etc. Why single out just a few types of bugs to crash the whole program? Let me catch it and decide what to do. If it’s in a single request to my web server, I’d like that single request return an error code. I would not like all other concurrent requests for all other users to fail as well.