Status 200 for errors is common for non-REST HTTP APIs. An application error isn’t an HTTP error, the request and response were both handled successfully.
Status 200 for errors is common for non-REST HTTP APIs. An application error isn’t an HTTP error, the request and response were both handled successfully.
There may be a need for additional information, there just isn’t any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a “400 bad request” response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.
This should be done with font ligatures, not replacing character combinations with other characters that can’t be typed normally
It’s a reach, but the Fourier transformation of a Schwarz (rapidly decaying) function is also a Schwarz function. Compact support is a strictly stronger condition than Schwarz (the function must eventually decay to 0) but doesn’t have this nice property with respect to Fourier transforms, i.e. the FT of a compactly supported function is Schwarz but not necessarily compactly supported
Don’t think it saves bandwidth unless it’s a DNS level block, which IT should also do but separately from uBO
You’re making assumptions about the control flow in a hypothetical piece of code…
What you’re saying is “descriptive method names aren’t a substitute for knowing how the code works.” That’s once again just a basic fact. It’s not “hiding,” it’s “organization.” Organization makes it easier to take a high level view of the code, it doesn’t preclude you from digging in at a lower level.
No, your argument is equally applicable to all methods. The idea that a method hides implementation details is not a real criticism, it’s just a basic fact.
Eddie Bauer and Carhartt are my go-tos. Both carry tons of tall sizes. Wrangler has some too and may be cheaper.
No, not “almost every modern developer thinks inheritance is just bad.” They recognize that “prefer composition over inheritance” has merit. That doesn’t mean inheritance is itself a bad thing, just a situational one. The .NET and Java ecosystems are built out of largely object-oriented designs.
You realize this is just an argument against methods?
Java is a fine choice. Much prefer it over pseudocode.
I have read programs a lot shorter than 500 lines which I don’t have the expertise to write.
I worked with Progress via an ERP that had been untouched and unsupported for almost 20 years. Damn easy to break stuff, more footguns than SQL somehow
This has nothing to do with Windows or Linux. Crowdstrike has in fact broken Linux installs in a fairly similar way before.
Sure, throw people in jail who haven’t committed a crime, that’ll fix all kinds of systemic issues
Catch and then what? Return to what?
Dunno what you’re trying to say. Yes, if ZFC is inconsistent it would be an issue, but in the unlikely event this is discovered, it would be overwhelmingly probable that a similar set of axioms could be used in a way which is transparent to the vast majority of mathematics. Incompleteness is more likely and less of an issue.
It’s called speed of lobsters