5 ms·

I hate it that so many programming languages lie to users. > We don’t support exceptions, all errors must be declared and manually propagated > however, `pani

by tomp 3y ago

I hate it that so many programming languages lie to users. > We don’t support exceptions, all errors must be declared and manually propagated > however, `panic` Like, just admit you support a poor man’s version of exceptions. Similar to how Go took a decade to admit that (1) generics are useful, and (2) generics are already supported, by builtin types

heinrich5991 3y ago
I think there's a difference in culture between panic and exceptions. Panics are usually reserved for violated invariants, programmer errors. Exceptions are used for normal errors.
- otikik 3y ago
  "What are exceptions used for" is similar to tabs versus spaces. Many languages just "leave that part to the user". Which I think is wrong. Or at least, inefficient. Different people will make different assumptions and then we will have a clash of opinions.
  - davedx 3y ago
    Yeah, the amount of bike shedding and yak shaving I've been pulled into over "how exceptions should be used" is pretty dismal. The worst thing is, I've still not even 100% decided myself. I think that does say something about the design of exceptions.
    - shrimp_emoji 3y ago
      They should not be used.
      - davedx 3y ago
        Well I definitely disagree on that. I fall more on the side of “use them for regular errors too” because IMO anything that reduces boilerplate is a good thing. But I also don’t like “magic” so it’s still a bit in tension in my head
      - tomp 3y ago
        What happens when 1/0 though? Or socket disconnects?
  - norir 3y ago
    It's all about definitions. For me, the difference between exceptions and panics is the former is recoverable. You can write a language with panic but no catch to ensure that panic crashes the whole program every time it is invoked. let x = if foo then bar else panic("unhandled case !foo") end Panic allows you to enumerate cases without implementing them, which can be very helpful in development. As I build out functionality, my code crashes exactly where I need to implement the new case, but I can implement the initial happy path all the way to completion. try/catch on the other hand, I'm not a fan.
- troupo 3y ago
  It's either "fearless concurrency for highly scalable applications" or panic. Your threads will panic. They will throw exceptions. You will end up dividing by zero at 3 AM on a Christmas. If your own answer to exceptions is "yeah, the program just crashes and burns", you're doing everything wrong. It took Go and Rust over a decade to realise that and add poor man's excuses for handling panic. But exceptions are inevitable, and your language must provide good ways of dealing with them. See Erlang's approach for how to do it right.

by tomp 3y ago

heinrich5991 3y ago

I think there's a difference in culture between panic and exceptions. Panics are usually reserved for violated invariants, programmer errors. Exceptions are used for normal errors.

otikik 3y ago
"What are exceptions used for" is similar to tabs versus spaces. Many languages just "leave that part to the user". Which I think is wrong. Or at least, inefficient. Different people will make different assumptions and then we will have a clash of opinions.
- davedx 3y ago
  Yeah, the amount of bike shedding and yak shaving I've been pulled into over "how exceptions should be used" is pretty dismal. The worst thing is, I've still not even 100% decided myself. I think that does say something about the design of exceptions.
  - shrimp_emoji 3y ago
    They should not be used.
    - davedx 3y ago
      Well I definitely disagree on that. I fall more on the side of “use them for regular errors too” because IMO anything that reduces boilerplate is a good thing. But I also don’t like “magic” so it’s still a bit in tension in my head
    - tomp 3y ago
      What happens when 1/0 though? Or socket disconnects?
- norir 3y ago
  It's all about definitions. For me, the difference between exceptions and panics is the former is recoverable. You can write a language with panic but no catch to ensure that panic crashes the whole program every time it is invoked. let x = if foo then bar else panic("unhandled case !foo") end Panic allows you to enumerate cases without implementing them, which can be very helpful in development. As I build out functionality, my code crashes exactly where I need to implement the new case, but I can implement the initial happy path all the way to completion. try/catch on the other hand, I'm not a fan.
troupo 3y ago
It's either "fearless concurrency for highly scalable applications" or panic. Your threads will panic. They will throw exceptions. You will end up dividing by zero at 3 AM on a Christmas. If your own answer to exceptions is "yeah, the program just crashes and burns", you're doing everything wrong. It took Go and Rust over a decade to realise that and add poor man's excuses for handling panic. But exceptions are inevitable, and your language must provide good ways of dealing with them. See Erlang's approach for how to do it right.