> Why though? What do you gain other than longer stacktraces with all those wrappers? People always trot out some theoretical notion that a caller is going to catch that framework's different exceptions and handle them differently, but have you ever seen calling code that actually did that?
You've never seen a try that has more than 1 catch block for different exception types?
> There are many different kinds of values. There really aren't that many different kinds of error - there's "transient error that you might want to retry", "programmer called the API wrong", and that's about it, most other cases (like bad user input) probably shouldn't be exceptions.
Do you think bad user input should be a result type? Because exceptions are essentially the same thing.
You've hit on a couple of problems with exceptions in Java though. The first is I think the default for checked exceptions should be no stack trace. As the designer of the method you've left it to the caller to decide to handle it or not, if they choose to turn it into an unchecked exception then I believe that is where the stack trace should start from. Assuming there's enough context in the checked exception the designer of the method gave you everything you needed to handle it so why do we need to capture that part of the stack trace? If it ends up getting logged the source of the issue was where it was changed to an unchecked exception.
The other issue comes down to usability. Try catch blocks aren't expressions so if you want to default something in the case of a checked exception it's a lot of low information density lines. Converting to an unchecked exception is also more ceremony than it really needs to be, but there's not really a reason why it couldn't be made simpler with some syntax sugar.
Not sure I'm following honestly. Your primary goes down and it fails over to the secondary (which becomes the primary), but if you can't boot how do you then get another secondary ready to fail over to again when the new primary inevitably fails?
Why would the law being different mean they wouldn't use 3DS though? Surely it'd cut out a good amount of fraud along with the realtime monitoring? I understand that US consumers don't have a stake in this, but can't all the banks just agree to enforce 3DS? I can't imagine Americans are going to stop using their cards because of a small amount of friction added
Being a burden on the healthcare system in a country that has nationalised healthcare is being a burden on everyone through increased taxes and reduced spending in areas the money could be more useful.
Those erratic behaviours you talk about are generally illegal in most countries as well with drink driving, public intoxication, assault laws etc.
Drinking does have some positives as well, pubs are one of the few third spaces we have remaining. I know there are alternatives, but there are people who won't socialise in a cafe or a book club, but will go to the pub to see the regulars. Considering lots of Western countries have loneliness epidemics I think there'd be a downside to removing that option.
Drinking does seem to lubricate social situations, weed can help with pain etc. The only upside from smoking for the individual as far as I can tell is that it fixes the problem it created from you being addicted to it i.e. you get calmer when you get your fix.
I think there is a reasonable argument to be made that they're a different degree of societal problem. I think there's quite a few people who drink on special occasions, but not every week or even every month (I'm one of them).
I think it's very rare though for a smoker to not smoke several a day. A friend of mine was that rare breed and would buy a 10 pack occasionally - usually on a Friday and it'd be gone by Monday - but that would maybe be once a month. I think every other smoker I've met though goes through that amount every day.
So it seems to me the average smoker is much more likely to become a burden on a nationalised health service than the average drinker. There's more to this of course, smoking to excess generally doesn't increase the chances of you getting into a fight like drinking does for some people, but social pressure counters that partially too.
I think it makes a good point that some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. To some degree that is a plus though as you likely trust the maintainers of your OS distribution to provide stable, supported libraries.
As other commenters have said, perhaps this is an area where the Rust maintainers could provide some kind of extended standard library where they don't guarantee backwards compatibility forever, but do provide guarantees about ongoing fixes for security issues.
This is a common complaint, but I think the controls are actually very tight. Usually the issue is that the player is struggling with travelling in a vacuum with a ship that can quickly get up to tens of thousands of km/h and it's very difficult to judge distances in space. I realise you're unlikely to go back if you've read a story synopsis, but for anyone else I would highly suggest locking on to your target and using the two numbers (your current speed relative to the object and the distance from the object) to judge how hot you're coming in.
It's not mandatory, there's 1 part in Dark Bramble where you can go a little faster if you use a very small amount of thrust. You can just use the momentum you came in on though, there's still plenty of time
Strange, I would have thought a pro rata refund would be allowable in these cases. I'm pretty sure that's how it works with insurance so I'm unsure why a toll pass would be any different.
There are signs that the blackout will have an affect on their bottomline if it's kept up [1]. I'd imagine that's why they're making these moves to remove moderators participating in the blackout so quickly. I think it'll be interesting to see if they can find other moderators who participate for free and bring as much value to reddit as the current mods do.
My guess is that the changes will still go ahead and the general quality of content on reddit will go down longer term although how much is an open question.
The absolute cost isn't a perfect measure for what I'm considering though because it will need to be compared to median real income. Looking at this: https://ec.europa.eu/eurostat/databrowser/view/ILC_MDED01__c... it appears housing is costing a bigger share of household disposable income over time in Switzerland
I realise the UK is starting in one of the worst positions for house price pressure, but it does seem to be a general trend in all Western countries. My point is that it seems like my potential children would need to work harder to get the same level of basic necessities. It might be getting tougher more slowly in some countries than others, but that doesn't meet the criterion I feel is necessary of mostly getting better for most people.
Perhaps I worded it poorly, but I meant housing as in a place to live regardless of if that's achieved via ownership or renting. Both are getting more expensive compared to median wage as we build less than the increase in population. I didn't think that was a uniquely British phenomenon, but I'd be happy to learn otherwise.
> If you grew up with $50M+ and lived a luxurious life, but lost it all, would you not have children over worries they may not have the same standard of living that you did?
I'd agree there's nuance to this. For your cherry picked scenario, no, that wouldn't affect my decision. I can accept a single person having a reduction in living standards. However, when most of Western society (I'm British, not American) is struggling to attain housing at a rate similar to the generation before, when the middle classes as a whole aren't able to become as financially secure as the generation before then it is enough to give me pause.
So ignoring any climate worries I already think things will be much harder. When you add on that it's estimated that billions will be without sufficient water in a few decades it's not hard to imagine that there will be significant problems of which I have very little confidence that we will be able to handle well as a species.
Perhaps I'm overly pessimistic. But as I say, this isn't the only factor we've taken into account, it's more a tertiary concern.
You've never seen a try that has more than 1 catch block for different exception types?
> There are many different kinds of values. There really aren't that many different kinds of error - there's "transient error that you might want to retry", "programmer called the API wrong", and that's about it, most other cases (like bad user input) probably shouldn't be exceptions.
Do you think bad user input should be a result type? Because exceptions are essentially the same thing.
You've hit on a couple of problems with exceptions in Java though. The first is I think the default for checked exceptions should be no stack trace. As the designer of the method you've left it to the caller to decide to handle it or not, if they choose to turn it into an unchecked exception then I believe that is where the stack trace should start from. Assuming there's enough context in the checked exception the designer of the method gave you everything you needed to handle it so why do we need to capture that part of the stack trace? If it ends up getting logged the source of the issue was where it was changed to an unchecked exception.
The other issue comes down to usability. Try catch blocks aren't expressions so if you want to default something in the case of a checked exception it's a lot of low information density lines. Converting to an unchecked exception is also more ceremony than it really needs to be, but there's not really a reason why it couldn't be made simpler with some syntax sugar.