onimishra
Joined 7 years ago
Joined 7 years ago
Taken from the product site (not this blog post) that was linked by another user. So you get to choose it would seem.
Isn’t that the entire thing the article argues? That journalism (real journalism, that is meant to keep those in power on the straight and narrow), suffers because not enough money goes to the actual journalists? Stock is the public’s perception of something’s value, but the actual value to society can not be measured in stocks.
That being said, 6 months is a perfectly reasonable time for an employment that you’ve found unreasonable. If I’d see something like that on a resume when I was hiring, I might ask a question about the short stay during the interview process, but an answer about mis-matched culture fit would be perfectly legit for me.
He went on to make Typescript - making sure that JS has types, so when making method calls you could have the compiler tell you when you did something wrong. Again, errors/exceptions did not get a throw clause, making it impossible to model the error state that the language provides. You can describe, in detail, the data for successful run, but are unable to describe the data for any error state. If the goal was to make the system more sound, I have a hard time seeing why the error state is not taken into account.
A lot of the described (and for myself experienced) cases against checked exceptions comes from external libraries or the language itself. IOException has a special place in hell, but for my own business logic (or inherited legacy code) in an application that spans thousands of files and classes, I would very much like to describe and be made aware of the error state throughout my application.
In Java, if I introduce a new business logic error state, all the places in my http (or cli or whatever) layer that uses that business logic will get highlighted for me, and I can then map it accordingly. In C#, that is not the case. If I don’t want checked exceptions, I can always catch it and throw a runtime exception - but I have the option. As a developer who likes to think I know what I’m doing, I would at least like the option. In C#, that decision was never mine.
With TS, we have a system that lives around being configurable. One day, I would really like to see this being up to the developer and a parameter in the tsconfig file, maybe with a configurable list of error types to be considered RuntimeExceptions. That way, if I don’t agree with a library’s use of the feature, I can tell TS to not report them by considering them Runtime.
Might just be because I use an architecture that actually favors CheckedExceptions, but not being able to describe the error states of my business logic really grinds my gears ;)