You must have exceptionally competent first-level support.

There are no inherent “rules” to language, either, but when you don’t followthemthingsgetmessyandyou’reannoyingforeveryoneelese.

Thank you for linking the blog posts. They are a really good deterrent from Clean Code. I once thought I’d read it, but Fowler’s advice really is stupid.

In case you’re wondering why I replied three times: “Do one thing” :)

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of. The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development

They may be a part of software development, but they should not be common during the normal execution of software. I once read the hint, “if your app doesn’t run with all exception handlers removed, you are using exceptions in non-exceptional cases”.

Throwing an exception is a way to tell your calling function that you encountered a program state in which you do not know how to proceed safely. If your functions regularly throw errors at you, you didn’t follow their contract and (for instance) didn’t sanitize the data appropriately.

Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

I disagree here. You can always ignore an error return value and pretend that the “actual” value you got is correct. Ignoring an exception, on the other hand, requires the effort to first catch it and then write an empty error handler. Also (taking go as an inspiration), I (personally) find this very hard to read:

res, error = try_something()
if error {
  handle_the_error(error)
  return_own_error()
}
res2, error2 = try_something_else(res)
if error2 {
  handle_other_error(error2)
  return_own_error()
}
res3, error3 = try_yet_something_else(res2)
if error3 {
  handle_the_third_error(error3)
  return_own_error()
}
return res3

This code mingles two separate things: The “normal” flow of the program, which is supposed to facilitate a business case, and error handling.

In this example, on the other hand, you can easily figure out the flow of data and how it relates to the function’s purpose and ignore possible errors. Or you can concentrate on the error handling, if you so choose. But you don’t have to do both simultaneously:

try {
  res = try_something()
  res2 = try_something_else(res)
  res3 = try_yet_something_else(res2)
  return res3
} catch (e) {
  // check which error it is and handle it appropriately
  throw_own_exception()
}

Functions should be small and do one thing […] you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together

I believe you have a wrong idea of what “one thing” is. This comes together with “functions should not mix levels of abstraction” (cited from the first blog entry you referenced). In a very low-level library, “one thing” may be sending an IP packet over a network interface. Higher up, “one thing” may be establishing a database connection. Even higher up, “one thing” may be querying a list of users from the database, and higher up yet again is responding to the GET /users http request. All of these functions do ‘one thing’, but they rely on calls to a few methods that are further down on the abstraction scheme.

By allowing each function to do ‘one thing’, you decompose the huge problem that responding to an HTTP request actually is into more manageable chunks. When you figure out what a function does, it’s way easier to see that the function connectToDb will not be responsible for why all users are suddenly called "Bob". You’ll look into the http handler first, and if that’s not responsible, into getUsersFromDb, and then check what sendQuery does. If all methods truly do one thing, you’ll be certain that checkAuthorization will not be related to the problem.

Tell me if I just didn’t get the point you were trying to make.

Edit: I just read

Martin says that functions should not be large enough to hold nested control structures (conditionals and loops); equivalently, they should not be indented to more than two levels. He says blocks should be one line long, consisting probably of a single function call. […] Most bizarrely, Martin asserts that an ideal function is two to four lines of code long.

If that’s the standard of “doing one thing”, then I agree with you. This is stupid.

From your description this sounds more like a job in IBM’s R&D department than a game

No, it does.

In Mint: Externen Monitor anschließen geht nur, nachdem man Treiber nachinstalliert hat. Zwischen externem Monitor und internem ist eine Lücke von geschätzt 800 Pixeln. Skalierung für jeden Bildschirm separat einstellen, geht gar nicht. Externe Lautsprecher brummen auf voller Lautstärke, wenn kein Ton abgespielt wird, was ich bisher nur nach Login und vor Logout reparieren konnte.

Ubuntu: WLAN geht nicht

Manjaro: Hier sind 500 Paket-Updates, finde selbst raus, wie du die Konflikte reparierst.

Solange so ein Krempel nicht „einfach funktioniert“, ist Linux kein Herr und Erlöser.

Infuriatingly long and badly communicated Windows update today, at work, which I wanted to install during the break, only to find that the laptop crashed midway and I still had to do the update when I came back.

The best part is when Windows tries to reboot, but the Dell laptop decides that it won’t have any of that and crashes, so you come back from your break you find yourself in the BIOS and the update didn’t install after all.

Dell, not even once.

I’ve had that happen to me, too, and I think it’s lying to us. Windows doesn’t need to reboot, it needs to do some cleanup work and then reboot. Only it doesn’t tell us that.

Der Witz geht auf dich. Bluetooth hat unter Linux bei mir schon immer funktioniert, während egal-welcher-Treiber unter Windows keine Verbindung zustande bringt.

Absolutely! Windows has every chance to download the update before the process starts, do whatever computing is required and then just swap files upon the next reboot. This shouldn’t take more than a few seconds on an SSD.

So true and yet so hurtful.

No need to specify the tag name in the selector if you’re going to use an ID anyway.

When be coding?

Microsoft gives no warranty and assumes no responsibility as it is.

Linux: Keeps the same quirks in shells alive for half a century BeCaUsE bAcKwArDs CoMpAtIbIlItY.

Also Linux:

it is literally impossible to use regular expressions to parse languages that aren’t regular

It’s impossible to parse the whole syntax tree, but that doesn’t mean you can’t get the subset you’re interested in.

Even better when the thing eventually breaks

You mean when it finally does become your problem?

Frankly that there isn’t a specific field signalling authorized/not-authorized

The instance I was bitching about was this: There’s a lot of region-specific data coming from the backend. But the user is only authorized for certain regions. So for instance the North-American guy gets this object: { "CA": [/* list of stuff */], "US": [/* list of stuff */], "MX": [ /* list of stuff */ ]}, while the US-only guy only gets {"US": [ /* list of stuff */] }. Are you suggesting that the response should also include flags isCaPresent, isUsPresent, isMxPresent for every country?

The issue with null vs not present surfaced because I, the frontend, checked if the returned object contained the key "CA" and then tried to iterate over the list of stuff, which happened to be null, which is hard to iterate over. I agree that I could’ve checked if the key was present and not null.

The meme, however, was lamenting that the backend developer, refuses to acknowledge that these two JSONs are different,since they only see their POJOs, where both map to CA: null, US: [], MX: null.

try to stick with integers in a currency’s smallest unit of division

And then the marketing department comes up with products that cost 1.5ct apiece.

Both instances are legal serialized JSON. What makes you think otherwise?

So it sounds like an issue with […] handling per-spec the presence of data which you don’t use.

The trouble is, in this specific use case, the data may either be there or it may not be, depending on authorization. I’m checking specifically if the key is present to determine whether the user has access to that data (and display a toggle for that data), or if the user mustn’t see it and thus doesn’t need the toggle.

The wrong assumption was that if the key is there, then the value is not null. That assumption was invalidated by an update on the server side. Of course I could’ve checked if the value of the key is nullish. But it’s still annoying to have a breaking frontend because the backend changed how it serves its data.

Holy shit, I’m sorry.

Though I once proposed an API like that for user preferences. I just needed “someone” (that wasn’t the client) to store a bunch of data for me. The backend doesn’t interpret it, the backend doesn’t edit it, so why should they deserialize and serialize it again? Just give it to me when I ask for it, kay?

To be fair, just because obj.foo is undefined, that doesn’t mean the key is missing. It could also be assigned the value undefined. const obj = { foo: undefined } vs const obj = {}

If an attribute is null, I would prefer to simply not serialize it.

That’s interesting. I’m on the opposite team. If a customer model defines an optional birthday, for instance, I’d rather have it serialized as a null value if it’s not available for a specific customer.

Indeed, and that turns out to be a problem if the JavaScript expects the key not to be there, but instead it is there. And then you try to tell the backend dev that the key shouldn’t be there, but he’ll try to convince you that it’s the same whether the key is not there or whether it’s assigned null and then you wonder if he’s messing with you, but actually he isn’t and then the only thing keeping you sane is bitching about it in meme form on lemmy.