Earlier quoted context omitted.
> I think Rich Hickey has a point that bugs like this almost certain get caught by running the program. That is certainly correct... but that doesn't make it a good thing. One wants to catch bugs before the program is running, not after.
Depends which is quicker. If I catch a trivial bug on the first run, I just saved myself writing the type system to find it ahead of time.
Use Your Type System
321–330 of 357 posts
Re: Use Your Type System
#322Earlier quoted context omitted.
Yep. For this reason, I wish more languages supported bound integers. Eg, rather than saying x: u32, I want to be able to use the type system to constrain x to the range of [0, 10). This would allow for some nice properties. It would also enable a bunch of small optimisations in our languages that we can't have today. Eg, I could make an integer that must fall within my array bounds. Then I don't need to do bounds ch…
Ada has this ability to define ranges for subtypes. I wish language designers would look at Ada more often.
Re: Use Your Type System
#323Earlier quoted context omitted.
If only Java also provided Either -like in the standard library... Personally I use checked exceptions whenever I can't use Either and avoid unchecked like a plague. Yeah, it's pretty sad Java language designer just completely deserted exception handling. I don't think there's any kind of improvement related to exceptions between Java 8 and 24.
Ok please help me understand, what is the difference between - R method() throws L, and - Either method() To me they seem completely isomorphic?
Semantically from CS point of view in language semantics and type system modelling, they are equivalent in puporse, as you are very well asking about.
Re: Use Your Type System
#324Earlier quoted context omitted.
> So Java's checked exceptions force you to write verbose and pointless code in all the wrong places (the "in the middle" code that can't handle and doesn't care about the exception). It doesn't, you can just declare that the function throws these as well, you don't have to handle it directly.
It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method. This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.
Re: Use Your Type System
#325An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…
C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue. I also think its a bit cleaner to have a nicely pattern matched handler blocks than bespoke handling at every level. That said, if unwrapped error results have a robust layout then its probably pretty equivalent.
Re: Use Your Type System
#326Earlier quoted context omitted.
It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method. This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.
You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?
To solve this, Rust does allow you to just Box (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.
Re: Use Your Type System
#327Earlier quoted context omitted.
You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?
Yes, the exact same problem is present in languages where "errors are just values". To solve this, Rust does allow you to just Box (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.
It took until version 1.13 to have something better, and even now too many people still do errors.New("....."), because so is Go world.
Re: Use Your Type System
#328[1] https://www.velopen.com/blog/adding-type-safety-to-object-id...
Re: Use Your Type System
#329Earlier quoted context omitted.
C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue. I also think its a bit cleaner to have a nicely pattern matched handler blocks than bespoke handling at every level. That said, if unwrapped error results have a robust layout then its probably pretty equivalent.
Until routinely prod goes down with that exception that no one cared to handle, been there done that.
Maybe you mean requests are failing on uncaught exceptions, in which case I'd say it's working well.
Re: Use Your Type System
#330Earlier quoted context omitted.
Until routinely prod goes down with that exception that no one cared to handle, been there done that.
For something like a web request, all the frameworks catch the exception at the request level. Prod should not be going down. Maybe you mean requests are failing on uncaught exceptions, in which case I'd say it's working well.
Or if they are unable to work, because they keep getting a maintenance page, as the load balancer redirects them after several HTTP 500 responses.