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.
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.
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
.
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?
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.
You must have exceptionally competent first-level support.