3 ms·

I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling a

I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. And they don't give you a stack trace, which is a lifesaver for development and debugging. Plain old unchecked exceptions work better. Probably cheaper too, because sum types require wrapping and unwrapping at each step, while exceptions can be very cheap when not thrown.

KirinDave 8y ago
> I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. I hear this parroted a lot, and I really don't get it. When an exception happens, you can't resume control flow (unless you're in Common Lisp, which has an objectively better system for exceptions than any we use). In that case, you're right that specific type and details don't matter. But if you get the failure value back as part of the control flow with a precise type then you can actually recover from it. People quote the Erlang philosophy out-of-context suggesting this is Actually Always Bad. It's not! You might want to: provide a default value for a server (bind to 127.0.0.1 or 0.0.0.0), synthesize a default templated configuration file, propose a valid algorithm over a forbidden one in a cryptographic negotiation, etc. > Plain old unchecked exceptions work better. Probably cheaper too, because sum types require wrapping and unwrapping at each step, while exceptions can be very cheap when not thrown. I'd be surprised if that was the case. Stack unwinding and introspection looking for handlers is infamously expensive whereas reading fields from a struct on the stack is seldom considered very expensive. Even if you do have an on-heap indirection that breaks locality, it's not like firing off a random class handlers further up the stack is gonna be BETTER for locality. Given that `finally` exists and objects have destructors, an exception up-stack is often a lot more code than it looks like.
- cousin_it 8y ago
  Yeah, agreed that exceptions make the exceptional path more expensive. But I think the normal path is cheaper. I'm not sold on resumable exceptions. It makes more sense to pass default values directly. Have you seen this bit in Stroustrup's book: http://www.cpptips.com/term_except http://www.cpptips.com/term_except
  - KirinDave 8y ago
    Actually, I'm not entirely right here. Joe Groff caught up with me on twitter and explained to me that because Swift requires you to check exceptions, it actually generates static logic at the call site. This means handlers have a cost on both sides of the "railway", but it means that exception handling has a fairly optimal codepath. It'll still be cheaper to do a simple pattern match into a struct for complex handlers, but for depth 1 they should essentially be identical. That's a very interesting tradeoff for the Swift compiler!

KirinDave 8y ago

> I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. I hear this parroted a lot, and I really don't get it. When an exception happens, you can't resume control flow (unless you're in Common Lisp, which has an objectively better system for exceptions than any we use). In that case, you're right that specific type and details don't matter. But if you get the failure value back as part of the control flow with a precise type then you can actually recover from it. People quote the Erlang philosophy out-of-context suggesting this is Actually Always Bad. It's not! You might want to: provide a default value for a server (bind to 127.0.0.1 or 0.0.0.0), synthesize a default templated configuration file, propose a valid algorithm over a forbidden one in a cryptographic negotiation, etc. > Plain old unchecked exceptions work better. Probably cheaper too, because sum types require wrapping and unwrapping at each step, while exceptions can be very cheap when not thrown. I'd be surprised if that was the case. Stack unwinding and introspection looking for handlers is infamously expensive whereas reading fields from a struct on the stack is seldom considered very expensive. Even if you do have an on-heap indirection that breaks locality, it's not like firing off a random class handlers further up the stack is gonna be BETTER for locality. Given that `finally` exists and objects have destructors, an exception up-stack is often a lot more code than it looks like.

cousin_it 8y ago
Yeah, agreed that exceptions make the exceptional path more expensive. But I think the normal path is cheaper. I'm not sold on resumable exceptions. It makes more sense to pass default values directly. Have you seen this bit in Stroustrup's book: http://www.cpptips.com/term_except http://www.cpptips.com/term_except
- KirinDave 8y ago
  Actually, I'm not entirely right here. Joe Groff caught up with me on twitter and explained to me that because Swift requires you to check exceptions, it actually generates static logic at the call site. This means handlers have a cost on both sides of the "railway", but it means that exception handling has a fairly optimal codepath. It'll still be cheaper to do a simple pattern match into a struct for complex handlers, but for depth 1 they should essentially be identical. That's a very interesting tradeoff for the Swift compiler!