Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Mention another benefit of Hegel in the documentation #365

Open
flowstate247 opened this issue Jun 17, 2022 · 1 comment
Open

Mention another benefit of Hegel in the documentation #365

flowstate247 opened this issue Jun 17, 2022 · 1 comment

Comments

@flowstate247
Copy link

flowstate247 commented Jun 17, 2022

There is an advantage that I discovered Hegel has compared to Java, TypeScript and Flow that should be mentioned in the documentation in my opinion.

I explained it in these TypeScript issues:
microsoft/TypeScript#49549
microsoft/TypeScript#49582

Basically the way Hegel treats type propagation, in conjunction with the never type, makes it possible to get rid of the whole verbose throws Java-esque mechanism that would otherwise be required to be safe in the Java language, and that is missed entirely in TypeScript and Flow making those languages unsafe.

@Yamboy1
Copy link

Yamboy1 commented Oct 25, 2022

I've found in previous java projects that it's very easy to just wrap a checked exception with a try catch block that throws an unchecked exception, such as a RuntimeException, to get the error to go away. While I agree with this in principle, I feel like I'm practice, it gets more in the way than it is useful.

What I reckon would be more useful, is having jsdoc that annotates the different methods that are thrown. Maybe it could be possible to write tooling around checking the jsdoc and making sure that all errors brought up in jsdoc are handled, but I don't think modifying type syntax would be any more useful here than jsdoc.

Additionally jsdoc can provide more information about why an error exists, that couldn't be portrayed using types, and seriously, if you're not currently using jsdoc, you're missing out on very useful tooling, so an argument that it's extra tooling would be invalid imo

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants