>in places where it's pointless to check, like IOException
Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?
I don't think I can recall a time where I routed-around-the-damage on the basis of a particular typed exception.
As soon as you consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff.
As soon as you start thinking about the above, it becomes immediately obvious that low-level calls should not be able to decide to re-run themselves.
I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?
Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of
try {
...
} finally() {
...
}
to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit but you can do much worse. That is, you want a default "sloppy" error handling approach that's correct that you can do without thinking and avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.
> avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
That's a code style and code review issue; each project has so set standards regarding how errors are dealt with and enforce them throughput the codebase.
But from a quality standpoint there are three concerns:
(1) Do you actually do the code review, do you actually enforce the style?
I worked on a Scala project where the dev manager thought it was preferable to handle errors with monads and would be vociferous about what a great practice that was compared to exceptions and that code review was central to how we do things... but if you looked at the code most of the time errors just got dropped silently and that was the same for many practices that the dev manager told me were doing but that we don't. He still posts on LinkedIn complaining about other dev managers who say they do code review but really don't. Practically that code didn't consistently give the right answers and poor error handling was one reason, another was that they never really understood that teardown was just as important as initialization.
(2) Is your documented practice correct? Is it really doing the right thing?
In a lot of cases there really is a right and wrong way to do things (e.g. uv resolves Python dependencies properly, pip doesn't) but it's less clear in error handling, like sometimes things went wrong and there is no way you can make it right and you can do the best that you can.
The global nature of the problem is vexing. Like an IOException might really be a BackhoeCutAFiberSomewhereInWisconsinException and a segmentation fault is occasionally a YouAskedForAOneAndGotAZeroInsteadException and it's not just academic because, given an exception, you want to answer questions like "Should I retry this operation? How long should I wait before I retry this operation?"
(3) Is this practice something you can sustain? How hard is to do? How much cognitive load does it add and how does it interact with other practices? "Throw up as much as you can", "tear down in finally {}", "otherwise handle local consequences of errors and rethrow" and "really catch errors at the drivers of units of work" is a practice that really works in many languages and is pretty easy to do right, even code that is written without a lot of care will do the right thing or something close by default. I've seen a lot of "no plan for error handling" or "bad plan for error handling"... like I was traumatized by the first C program I saw in a 1984 issue of Byte magazine which was using errno to handle errors which vastly complicated very simple code because the error path was intimately wound with the happy path and in cases like that there tend to be bugs in both of them. When I saw Exceptions in Java I remembered that old C program and thought "I love this!"
Scala's ZIO also demonstrates that they're a great idea and can be perfectly ergonomic, but you need type inference, which Java devs were resistant to for a long time (maybe still are? I remember lots of "how will I ever know what `val a = new Animal()` is???"). If you infer the exception type, they're basically invisible except for when you forget to have some place in your program to handle them, which is exactly what you want.
Oh, then do explain the unbearable temp that we're going through last few years, that's completely not normal for my country, winters not needing worm clothes, and very little rain during the monsoon. This weeks heatwave left us wondering how to cope the next year, which already seems going to be worse
It makes us realize there are people who gets fed climate denying propaganda, simply because they're not yet going through it. And these people are like flat earthers, blind to see the reality lay beyond them in full view. Or worse sees the reality but ignores it
All I know is that in the 80s a scientist I respect predicted that coral would be bleached by changing global climate on a specific timeline which turned out to be spot on, and his advice then and now was that we need to seriously curb carbon emissions to avoid worse outcomes for life on earth. Until someone opposed to this suggestion comes up with a prediction equally as long range and impressive I'm afraid I can't really take their protests too seriously.
Right, and one of those industries is checks notes orders of magnitude smaller than the industries and secondary industries that benefit from denying climate change.
Really makes one think, if they try. Would need to ask Claude if there is some real middle ground here.
I've come to the point where I've thrown up my hands and decided we live in a little snow globe. There's no such thing as pollution, were just mixing existing things together. Nothing new under the sun. Sure, that mix might not be compatible with human life, but something will surely take its place. And maybe that something won't rely on selfishness to drive collective progress the way we do.
At some point you realise that an $11tn industry, with $7tn in handouts and subsidies every year, has spent billions on astroturfing, political capture, and straight PR to deny the obvious and keep itself on life support at the expense of everyone else.
There's no both sides here. One side is staffed by scientists, the other by dictators and corporate lunatics.
I'd say the exception is Demis. First, he's no wanker (in the AI space) and second he's done plenty of selfless things leading dm/googai. Obviously some of it is self-serving but not just self-serving, IMO.
whats crazy is that we got here and it isn't even the midterms yet, who knows how cranky folks are going to get if the midterms don't go well for them.
I get the sentiment. But for the record, O&O has been around for a long time, they were known for their excellent defragmentation tool, which isn't so much required nowadays. Their business model was never close to Adware (to my knowledge).
ShutUp has also been around for a while and always seemed to me like a O&O side project by someone who got really pissed at Windows taking the spyware tangent. The distribution model is still that of shareware / freeware (no source), because that's what O&O does. But as far as closed software goes, that's _probably_ as clean as it gets.
Windows has had built in defrag since at least WinXP. I can't remember if Win2000 had it - I think it did. It runs in the background and you don't have to worry about it. 3rd party defrag tools are snake oil, like registry cleaners and so on.
IIRC W2K didn't have one. Defragmentation can use different strategies which may impact the time it takes and additional perf gains if the right files are next to each other. The builtin defrag tool doesn't give any option. So "snake oil" I'm not so sure.
Also, a watching a proper defragmenter run was an OCD soothing experience before we had stray kitten and powerwashing videos galore. I know I'm not alone with this experience.
I know for sure NT4 didn't have defragging built in, because I was a Windows server admin back in the primordial soup that was sysadmin'ing in the 90's.
>OCD soothing experience
I've always felt it was a certain kind of person who found amusement in watching a defragger work. I'm absolutely sure that 3rd party tools made sure to incorporate the equivalent blinkenlights to give the impression that their tool did something useful.
I'm pretty sure some versions of DOS had a defrag tool, or at least windows 9x had a DOS mode equivalent where you could see the block map getting moved around.
I wonder if people who are down-voting you actually have children. I even know someone who's kid just died in a pool when no one was watching... My kids almost drowned themselves multiple times when they were below 5 yr old and they are trained to swim... My brother fell into a pool when he was little, and had to be saved... the list goes on and on... edit: Apparently it's the leading cause of death for 1-4 year olds...
A sizable portion of the blue collar economy collapses too if the white collar portion stops having money to spend or suddenly has an influx of time to do some of the stuff the blue collar workers were doing for them like lawns, home repair, painting etc.
Its all tied together. The current system cannot function if unemployment goes double digits.
The idea is to break the middle class. Blue or white collar it doesn’t matter. A politically active middle class is a danger to the designs of Silicon Valley ghouls.
Using them correctly can be great tho.
reply