> 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.
> You've never seen a try that has more than 1 catch block for different exception types?
I've seen it for APIs that throw exceptions for bad input or whatever. But what I've never seen is more than one catch block for wrapper exceptions (except perhaps to unwrap the cause), where the calling code handles FrameworkNetworkError differently from FrameworkDatabaseError or what have you.
> Do you think bad user input should be a result type?
Yes
> Because exceptions are essentially the same thing.
Well, except for all the ways they're not that you mentioned in the following paragraphs.
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?
There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).
In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.
I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).
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
They could, but it's one of those things that really only work if everybody joins. Because 3DS is rarely used right now, a portion of merchants don't even support it, so if you start enforcing is as a single bank, your customers will start complaining their card doesn't work. The banking industry in the US is also more decentralized than in the EU, so getting everybody to join in simultaneously is hard.
The window of opportunity for 3DS has also more or less passed, the industry is moving on to the next generation of tech (wallets/tokenization), that should be both easier to use and more secure.
Because adding friction will deter many impulse purchases. Americans use credit cards constantly. The equilibrium would be perturbed in a way very much not advantageous for the credit card issuers if consumers became more cautious about using credit cards.
It’s the same reason credit card issuers are willing to pay Apple a few basis points to participate in Apple Pay: reducing friction has a non-linear impact on propensity to pay.
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.
Smoking may be a burden on the healthcare system, but the effects of alcohol are a burden to everyone due to the resulting erratic and often directly destructive behavior.
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 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.
> 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.
The point wasn't so much about the loading mechanism, but about the fact that the system (especially on Linux) provides them for you; a good amount come pre-installed, and the rest go through a system package manager so you don't have to worry about the language failing to have a good package system.
> some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded.
Not in my case. I manually compile all the dependencies (either because I need to cross-compile, or because I may need to patch them, etc). So I clearly see all the transitive dependencies I need in C++. And I need a lot less than in Rust, by a long shot.
Part of the rust dependency issue is that the compiler only multithreads at the crate level currently (slowly being improved on nightly, but there's still some bugs before they can roll out the parallel compiler), so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile.
edit: Also, `cargo-vet` is useful for distributed auditing of crates. There's also `cargo-crev`, but afaik it doesn't have buy in from the megacorps like cargo-vet and last I checked didn't have as many/as consistent reviews.
It can do. Additionally, because each part is now smaller it's now easier to ensure that each part, in isolation, does what it says on the tin. It also means that other projects can reuse the parts. An example of the last point would be the Regex crate.
Regex is split into subcrates, one of which is regex-syntax: the parser. But that crate is also a dependency of over 150 other crates, including lalrpop, proptest, treesitter, and polars. So other projects have benefited from Regex being split up.
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
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.