C vs C++, from the author of ZeroMQ
-
You're a nitpicky nitwit who likes to quote half sentences at people, which is a terrible habit that is likely to end up getting people to punch you in the nose.
And you're a spiteful hater who reads only half of a post and criticizes it on the spot, willfully overlooking that I quoted the other half just below and gave it an appropriate comment too.
-
Also, I forgot to mention last time how I absolutely despise the fact you're showing off your elitism by using a double-sized hyphen which, while actually more correct than regular one, don't improve readability at all, and take much more effort to write, thus the only reason you used them was to make yourself look special compared to others. Asshole.
-
So we're now discussing semantics.
In as much as we're arguing over what error handling means, yes. We're arguing semantics. However, it would have been nice if you'd commented on the more concise definition I added at the end:
The goal of error handling is ensuring the system transitions to a predictable state in case of errors.
Do you disagree with this definition? Can you provide a better definition of what error handling is? If not, can you describe in what way "deciding not to use soap" is not a transition to a predictable state?
-
and take much more effort to write
You just need a different keyboard configuration. It's not difficult for me.
Asshole.
;)
-
The goal of error handling is ensuring the system transitions to a predictable state in case of errors.
Do you disagree with this definition?
Well, it's kinda a trick question. It's not a definition, it's quality of error handling. Yes, error handling ensures system behaves predictably in case of errors. But it isn't the only way to achieve this predictability.My definition is that error handling is acting upon the error. It's the "else" clause in "if everything's good". You don't always need an else clause for an algorithm to be correct. Similarly, you don't always need to take special measaures if an error is encountered, aside from not running the part of code directly impacted by the error (if there's no file, you don't read from it). You still uphold all the API contracts - if you promised a usable texture, you return a usable texture. Also, the decision to handle or ignore an error is very local - if F1 calls F2 and F2 encounters error it can't recover from, it must escalate the error up the call stack. Because this is not part of clean path but extra steps taken, it's proper error handling. F1, however, might decide to ignore this error and continue anyway. In this situation, you both have and don't have error handling, depending on which POV you take (F1's or F2's).
-
I don't think it's a very useful definition, if a certain action can both "be error handling" and "not be error handling" depending on perspective. If you boss asks "Did you implement error handling for this procedure", he doesn't want to hear "yes and no, depending on where you are standing". It's also confusing, if you decide that in case of error you're going to skip a step and continue, to then tell your boss "we decided we're not handling errors here". It doesn't communicate that you've made a design decision and set it up so that the system can handle that error. It sounds as if you're refusing to do your job.
It's specially bad because by your definition, ignoring an error and reading from a null pointer, and reacting to the error by not reading from a null pointer, are both "not handling the error".
-
You're using a weird definition there. Error handling is in general ensuring that when an error — an exceptional condition — occurs, the overall system enters a predictable state. Nothing more funny than that. That error handling may be in the same function or in another one; the location of it does not make it handling of the error or otherwise. You're basically trying to impose a much stricter meaning than everyone else is using. You can persist in doing this, but you'll just find that everyone else continues to misunderstand you. Life is easier if we stick to common definitions.
Some functions, for some error conditions, just handle the error by punting it up to the caller. That's one of the simplest forms of error handling. Other simple forms just throw the error away and either repeat the action or go on to the next step in the function's processing. Again, those are not sophisticated approaches. Doing other things will typically require more effort.
A (somewhat) more sophisticated approach is to log the error before resuming or retrying, as that at least gives the developer a better chance to investigate what happened. For some applications, this logging is actually at the core of how errors are handled, and this is often linked to other strategies (such as transforming the error into a notification to the user, and rolling back any open database transactions); hybrid approaches are common. But it is important to note that not all errors should have the same handling code; a temporary networking problem (pretty common, alas, and so not something that ought to trigger an
abort()) would be often responded to very differently to a failure to allocate memory (which is often fatal, but rarely happens).
-
I don't think it's a very useful definition, if a certain action can both "be error handling" and "not be error handling" depending on perspective.
Yet velocity has great many real world uses.If you boss asks "Did you implement error handling for this procedure", he doesn't want to hear "yes and no, depending on where you are standing".
Actually, the answer to this question would be either yes xor no - if you consider a single procedure, everything is clear. It's when you consider whole use cases when it gets ambiguous. But it's a non-problem too, because the question will actually be "will the application be OK if error happens". Even if he worded it like you said he would.It's specially bad because by your definition, ignoring an error and reading from a null pointer, and reacting to the error by not reading from a null pointer, are both "not handling the error".
There's handling the error, and there's crashing on error. If you don't handle the error but still don't crash, you're good.
-
You're using a weird definition there.
Maybe, but that's because it's more useful (at least to me).Error handling is in general ensuring that when an error — an exceptional condition — occurs, the overall system enters a predictable state.
But if you do it in a way that doesn't need any explicit action to be taken in case of error, you have less code to maintain and most probably better and more straight forward design. That's why it's useful to distinguish those two ways to cope with errors.
-
If you don't handle the error but still don't crash, you're good.
No, you have a program in an unpredictable state
-
No, you have a program in an unpredictable state
If you never use this unpredictable state, it's equivalent to predictable state. Also, not all errors generate unpredictable state - failure to open a file, for example, makes everything perfectly predictable even if you don't do anything to ensure so.
-
failure to open a file
Isn't what I would consider an error. Anyway, if you don't detect the failure, how will you know the file handle is valid?
-
Isn't what I would consider an error.
Do all errors need to result in SIGSEGV to count?
Anyway, if you don't detect the failure, how will you know the file handle is valid?
If you use a file handle wrapper that, if the handle is invalid, returns empty stream instead of segfault, then you don't need to know if the handle is valid. Assuming empty files make sense in your use case (for a very relaxed definition of making sense).
-
-
Now you're just being stupid
And what can I tell about you and your "error while opening a file is not an error"?
-
If you don't handle the error but still don't crash, you're good.
See, this here is why your definition is useless. I can't tell if you mean "if you ignore an error and that doesn't lead to a crash, you're good", or if you mean "if you skip the steps that the error make impossible and that doesn't lead to a crash, you're good". If anyone else said it, I could at least be pretty certain they meant the first description.Both of which, as far as general statements go, are wrong for different reasons.
-
And I can't tell if by "useless" you mean useless or something entirely else, like confusing.
-
Both of which, as far as general statements go, are wrong for different reasons.
Why is skipping some steps not good, if the end result is good?
-
Also, if my definition of handling is confusing for you (and others), what term do you propose for "the way of handling an error that performs extra processing steps that aren't there in the clean execution path"?
-
How many posts in a row do you need to trigger Discourse warning?
-
Five seems not enough.
-
@RaceProUK said:
Now you're just being stupid
And what can I tell about you and your "error while opening a file is not an error"?
And what can I tell about you when you're moving the
-
A confusing statement in the middle of a conversation is useless, because it doesn't transmit your intended meaning. Which is the point of a conversation.
Why is skipping some steps not good, if the end result is good?
In the general case, "not crashing" is not the same as "good". If, for example, the user tries to save his work and you can't open the file to save, skipping the save step (or saving to a null object that is not a real file but just there to not crash) but continuing the rest of the save procedure, such as writing "file saved" to the UI, is worse than just crashing. If you crash, the user only loses the work he did since the last save. If you lie to him and say you saved, he will continue to work and lose all the work he does until he learns he wasn't actually saving.Which is why I say that it's wrong as a general statement. Sometimes skipping steps is fine, sometimes crashing is better.
what term do you propose for "the way of handling an error that performs extra processing steps that aren't there in the clean execution path"?
I call the block of code that specifically deals with an error an "error handler" (catch clause if I'm specifically talking about exceptions). Even doing something as basic as logging the error already requires an error handler to log that error, which are "extra processing steps that aren't there in the clean execution path".
-
And what can I tell about you when you're moving the goalposts?
You can tell what you want, but I'd be very glad if it answered my question about why failure to open file is not an error.
-
So now you've moved the
back, I can answer.The failure is not the error; the error is the cause of the failure.
-
A confusing statement in the middle of a conversation is useless, because it doesn't transmit your intended meaning.
I spent half of my posts in this topic on clarifying my usage of the word handling, and you seem to get it now. Is it still useless?In the general case, "not crashing" is not the same as "good".
Well, it was a bit of mental shortcut with that "not crashing". But I think it was a bit too much, and I should've made myself clear that I meant ignoring an error in the way that everything else is fine.If, for example, the user tries to save his work and you can't open the file to save, skipping the save step (or saving to a null object that is not a real file but just there to not crash) but continuing the rest of the save procedure, such as writing "file saved" to the UI, is worse than just crashing.
But of course it's worse! It's the end-user equivalent of breaking API contract! There's few things a programmer can do worse than that!I call the block of code that specifically deals with an error an "error handler" (catch clause if I'm specifically talking about exceptions).
Me too. And by extension, I call the inside of this block "error handling". And if there's no error handler, I don't call it error handling. But seems I was wrong. Besides, the term "error handling with error handlers" is almost as confusing as "error handling, but according to my own definition no one else uses"; I'd hazard a guess it might be even more confusing.Even doing something as basic as logging the error already requires an error handler to log that error, which are "extra processing steps that aren't there in the clean execution path".
I like to look at the code less literally and more conceptually. Then, all logs become unimportant additions that don't affect the logic of your code in any way - similar to no-ops. Then, your error handlers become empty, so they might as well be not there at all. That's why logging isn't error handling in my book. Also, note that I make a very strong distinction between logging an error and showing an error.
-
There are errors you're not meant to recover from. But if you don't log them, how will you know what to look for to fix the issues?
-
The failure is not the error; the error is the cause of the failure.
This deserves its own, unique, one-time only pedantic dickweed badge.
-
There are errors you're not meant to recover from. But if you don't log them, how will you know what to look for to fix the issues?
If you tag your posts properly, it makes easier for other people to tell interesting posts from trollbaits.
-
OK, explain how you're meant to recover from memory corruption.
-
I'm not obliged to explain anything if you totally misread my post.
-
Well, you seem to think you can recover from all errors, and therefore don't need logging. So I asked you how to recover from an error you should never attempt to recover from.
-
The failure is not the error; the error is the cause of the failure.
"The problem is not the problem. The problem is your attitude about the problem." -- Captain Jack SparrowIs it still useless?
Depends. Do you expect to have lengthy exchanges with everyone you mention error handling to, so they understand what you mean?
Then, your error handlers become empty, so they might as well be not there at all.
This may be where we disagree. "Choosing not to act is still choosing." I believe that purposefully not doing anything is a form of action. The corrective action being taken is "not doing anything". It is not the same as there not being a handler. In a well written problem, where errors are either handled or returned to the caller, a missing handler will eventually cause the error to reach main and the program to exit (meaning main exits with an error return instead of 0, which I call an abnormal exit if we want to distinguish from a crash which is the program calling abort or terminate).So even if we don't log the error, if we have an empty catch handler, that's making a decision. Handling the error. It tells future maintainers that there's nothing to do if we find a particular error and to just continue execution from the point of the handler onward.
-
Well, you seem to think you can recover from all errors, and therefore don't need logging.
I only seem to think that because you've got the part about my approach to code analysis totally back-asswards.
-
Then maybe you shouldn't give the impression you think logging is pointless
-
Depends. Do you expect to have lengthy exchanges with everyone you mention error handling to, so they understand what you mean?
No; just with you. Mostly because I just did anyway, so it doesn't hurt.This may be where we disagree. "Choosing not to act is still choosing." I believe that purposefully not doing anything is a form of action. The corrective action being taken is "not doing anything". It is not the same as there not being a handler.
That excludes the possibility of ever ignoring an error.In a well written problem, where errors are either handled or returned to the caller, a missing handler will eventually cause the error to reach main and the program to exit (meaning main exits with an error return instead of 0, which I call an abnormal exit if we want to distinguish from a crash which is the program calling abort or terminate).
Only if error is fatal. If it's non-fatal, and you are able to build an abstraction that allows treating non-error and error cases uniformly, you can let yourself never even check for error and still get the proper behavior in all possible cases.So even if we don't log the error
...but we do, because we're professionals...if we have an empty catch handler, that's making a decision.
Yes. I'm making the decision to ignore the error. But with your definition, ignoring is still handling. THAT'S confusing!
-
Then maybe you shouldn't give the impression you think logging is pointless
But it is pointless, from the algorhytm's point of view. It's useful for reasons totally detached from algorhytmics.
-
And what if your algorithm has an error that only manifests itself when you call an API? If you don't log the error, how will you be able to trace the cause?
-
[size=40]T.D.E.M.S.Y.R.![/size]
First, learn what an algorithm is. Second, understand the difference between errors and bugs. Only then you can question my techniques.
-
So an algorithm cannot include API calls now?
-
Can a number include a letter?
-
House numbers frequently contain letters
-
That excludes the possibility of ever ignoring an error.
From what you said, with error codes in Rust it creates a warning. So it's not impossible, it is just bad form. It is good that Rust gives you a warning though. In C++ with exceptions, it is impossible. Which I believe is better. But in C and C++ with error codes, there's pretty much no protection at all. And I imagine there are many other languages where it is possible to straight up ignore errors (and many others that do as Rust and provide warnings). When you speak with other people, you can't just assume that they use languages that follow Rust's conventions.
So "ignoring an error", while something that should never happen in Rust, is something that can and does happen in other languages. Where I work, code-reviews are the last line of defense against forgetting to check errors, thus ignoring them. So even if you see no value for the term in your particular niche, it is still valuable terminology everywhere else. For other people, ignoring an error means not checking the return value of a function and assuming it succeeded. Not "checking it and doing nothing in response".
Yes. I'm making the decision to ignore the error. But with your definition, ignoring is still handling. THAT'S confusing!
I hope I've now clarified what "ignoring an error" means for everyone else. Just to make it more explicit just in case, since I don't think I've spelled it out yet:Ignoring an error is calling a function that returns an error code, and not checking the error code before continuing,
-
Because when a programmer says numbers, he's most likely thinking of house numbers. Yeah.
You seem to have serious trouble thinking in abstract, non-real-life terms. You just can't separate the concept from its applications. It's truly impressive you've become a better programmer than average code monkey. Assuming you did.
-
Then allow me to learn the lesson from the almighty @Gaska that error handling must always be considered an afterthought, not something that should be integrated right from the start. I look forward to many years of writing terrible code with shitty error handling as a result.
-
(posting from mobile so no quoting)
Frankly, Kian, I'm now even more confused than before. I don't know anymore when you're talking about the concept of error handling, independent of language and technique used, and when you're talking about physically meddling with return values and exceptions. You seem to have similar problem with abstract thinking as @RaceProUK, but unlike him, I'll give you the benefit of doubt.
-
Then allow me to learn the lesson from the almighty @Gaska that error handling must always be considered an afterthought, not something that should be integrated right from the start
I'm outta here.
-
-
Frankly, Kian, I'm now even more confused than before. I don't know anymore when you're talking about the concept of error handling, independent of language and technique used, and when you're talking about physically meddling with return values and exceptions.
Well, I'm trying to use the terms in general, and providing examples of how the term applies to either exceptions or returning error codes. The reason I'm doing this, is because some of the things you said seem to imply that you are deeply embedded in how Rust does things specifically, so I'm trying to explain why the term has the name it has in other contexts.
Let me know what confused you when you're at a computer and I'll try to explain myself more clearly.
-
When you design an algorithm, you must consider its every step, every possible input, every possible outcome, every possible error. You do it independently of how you'll implement it - whether it's in FORTRAN or Haskell, the algorithm will be the same. Including errors. Including handling them. Which means you make decisions about handling, escalating or ignoring errors at the algorithm design stage. At this stage, there are no compiler warnings and no crashes to desktop. The algorithm can be equivalently implemented both using error returning and exceptions. In this context, saying "you can ignore errors because Rust throws warning instead of halting compilation" just doesn't make sense - it's not even wrong!
