C vs C++, from the author of ZeroMQ
-
So now you're saying you do take error handling into account.
-
Ok, we have different definitions for an algorithm, too. Yours is a lot more low level than mine, closer to what I'd call a procedure. For example, for me, binary search is an algorithm. It tells you how to do something. Implementing a binary search would be a procedure, and it would be specific to what is being searched, for example, and how comparison between the elements work, how they are stored, etc.
And I would never consider every possible error. I mean, my approach to errors is, by default, pass them to the caller. That handles most errors. It also means that I'm safe in case the functions I call have bad documentation and don't describe every possible error they might return.
The next question is, are there specific errors that I can do something about? If there are, I'd see how to handle those in the context of what I'm doing. So essentially, I only care about two kinds of errors; errors I can do something about, and everything else. Trying to think about what to do in case of every single error is a waste of time, since "pass it to the caller" is what you will almost always do. And it creates the possibility that you missed something, either because you had a lapse in concentration or were given bad documentation, which is now a weakness in your procedure. By assuming that anything could fail and that you don't know what every possible error could be, your program becomes more resilient, because you are by definition handling the unexpected, instead of only dealing with what you can expect at a particular point in time.
-
Ok, we have different definitions for an algorithm, too.
You've got to be kidding me. Algorithm is well-defined mathematical construct. There's only one definition that is correct. just like there is only one definition of circle, and it doesn't include the inside area.Yours is a lot more low level than mine, closer to what I'd call a procedure.
Procedure is a very ambiguous term, ranging from administrative law to subroutines.For example, for me, binary search is an algorithm. It tells you how to do something. Implementing a binary search would be a procedure, and it would be specific to what is being searched, for example, and how comparison between the elements work, how they are stored, etc.
Same here.And I would never consider every possible error. I mean, my approach to errors is, by default, pass them to the caller. That handles most errors. It also means that I'm safe in case the functions I call have bad documentation and don't describe every possible error they might return.
You have to put those error checks somewhere in the block diagram of your algorithm. If you don't, your algorithm is either broken, or is just a draft. Mind you, drafts are perfectly okay in most practical situations.So essentially, I only care about two kinds of errors; errors I can do something about, and everything else.
In other words, you care about every error. I know, bad wording - but still amusing, considering you're just trying to prove the opposite ;)And it creates the possibility that you missed something, either because you had a lapse in concentration or were given bad documentation, which is now a weakness in your procedure.
With exceptions, of course, it's awfully easy to overlook something. That's like, half of my point in the original discussion where I explained why I think exceptions aren't that good. With error returning (in Rust, because C sucks in this regard), it's impossible to miss something because all possible error conditions are right there in the interface!By assuming that anything could fail and that you don't know what every possible error could be, your program becomes more resilient, because you are by definition handling the unexpected, instead of only dealing with what you can expect at a particular point in time.
But this is not just defensive programming, which I absolutely hate, but also paranoid. It's sad it's the only way to be absolutely sure in C++.
-
discourse/lib/composer_messages_finder.rb at main · discourse/discourse
A platform for community discussion. Free, open, simple. - discourse/discourse
-
return unless
return if
God, Ruby is truly evil.
-
Comes from perl
-
If your evil features come from evil heritage, it's still evil.
-
it's impossible to miss something because all possible error conditions are right there in the interface!
Like checked exceptions in Java?
-
Yes. Kinda. Sorta. As close as you can get without exceptions, I guess. The biggest difference is that there's much, much, much less typing involved.
-
Java's seriously verbose, and it's one of the more annoying things about the language. Why use a 5 character name for something when you can use a 55 character name?
Combine that with the language's pettifogging officiousness and you've got a recipe for being prolix.Works quite well though, and has a lot of good third-party libraries. Even more rubbish, but the sheer size of the community has meant some good stuff has been made.
-
Where's @Gaska to wax poetic about the use of error checking here instead of exceptions?
I'm stuck in another thread, explaining to @RaceProUK that handling errors requires more effort than dumping random shit to log files.
-
Really? Because that's not what that chain reads like; it reads more like you casually disregarding the importance of proper error checking and exception handling.
-
Apparently, "logs are irrelevant to the workings of algorithm" means "fuck errors I'm Spiderman".
-
That's not what I said, and you know it.
@dkf said:Proper debate ought to not seek to misrepresent what the other side says.
-
Proper debate ought to not seek to misrepresent what the other side says.
I wish you applied this rule yourself, especially when you accused me of not caring about errors DURING A 200-POST LONG DEBATE WHERE I WAS ARGUING THAT ONE METHOD OF ERROR HANDLING IS BETTER THAN ANOTHER.BTW - in case you wonder, I do make logs. I make helluva lot logs. So much that I've got reprimanded once for writing too much logs, causing the operating system to scream in agony due to high load. Mind you, it's kinda-sorta-embedded programming, on very customized Linux and homebrew hardware.
-
-
I'm getting déjà vu about this discussion?
-
Which I never did
O RLY?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.
So now you're saying you do take error handling into account.
you casually disregarding the importance of proper error checking and exception handling
-
And none of those quotes backs up your baseless accusation.
Now, if you insist on reading what I didn't write, then you can probably guess what I'm not writing here.
-
@RaceProUK said:
@dkf said:
Proper debate ought to not seek to misrepresent what the other side says.
I do make logs. I make helluva lot logs.
-
This is getting a little heated. Are you two gonna be Ok?
-
I've got reprimanded once for writing too much logs, causing the operating system to scream in agony due to high load
Did those screams go to syslog?
-
This is getting a little heated.
Huh? Oh, that's because the heater's on; hang on a sec…
*turns heater off*
-
And none of those quotes backs up your baseless accusation.
OK, the first one isn't exactly accusing me of not handling errors, but about duct-taping all the error handling after the real work is done, not putting much thought into it. The third one is accusing me of thinking error handling is pointless, which is very very close to accusing of not handling errors, but not quite. The second one, however, is straight forward - by saying I do error handling now, I wasn't doing it then.This is getting a little heated. Are you two gonna be Ok?
But of course. I'm fiercely arguing just for fun.Did those screams go to syslog?
Yes. Ironic, isn't it?
-
Ironic, isn't it
What's really fun is when syslogd is getting hammered so hard that ksoftirqd starts to consume so much CPU time that other daemons start seeing timeouts and complaining to syslog about them. Happened to my cubietruck - whoever wrote the gigabit ethernet driver for the Allwinner SOCs thought it would be a good idea to spam syslog on every packet of VLAN traffic. Dunno if that's fixed now; went and bought a Beaglebone Black to use as my router instead
-
The second one, however, is straight forward - by saying I do error handling now, I wasn't doing it then.
Wonderful what you can do when you remove all context from a quote.
@Gaska said:The third one is accusing me of thinking error handling is pointless
No, it accuses you of having an overly-casual attitude to error handling.
-
We're not using syslogd but our very own service that handles all logging, file access, threading and IPC, among other things. Hence, the critical load is several orders of magnitude lower.
-
You should make that Pid 1 and put it in charge of reaping zombie processes as well. Just for completeness.
-
Wonderful what you can do when you remove all context from a quote.
The context was that I said algorithms don't include logging, to which you replied that you wonder how I track down errors in algorithms without logging. Then, later in discussion with @Kian, I said the algorithm should include handling (or not) of every error case possible, to which you replied that now I care about errors. So, your accusation is even more insane in context than out of context.
-
You should make that Pid 1 and put it in charge of reaping zombie processes as well. Just for completeness.
Except it runs on top of other services. It's meant as high-level abstraction over those things.
-
No, it accuses you of having an overly-casual attitude to error handling.
Which is false accusation anyway.
-
So, your accusation is even more insane in context than out of context.
I beg to differ; with the context, it's now clear the whole thing was about algorithms. That still leaves plenty of scope for other areas, in which I haven't passed any judgement at all.
@Gaska said:@RaceProUK said:
No, it accuses you of having an overly-casual attitude to error handling.
Which is false accusation anyway.
That it may be; I can only go by the words on the screen.
-
I beg to differ; with the context, it's now clear the whole thing was about algorithms.
Let me ask you this - do you really think logging is so important to algorithms that it should be specified what is logged where and when, in all UML diagrams and text descriptions of algorithm?That it may be; I can only go by the words on the screen.
I can only wonder what words made you think I write terrible code with shitty error handling.
-
-
Let me ask you this - do you really think logging is so important to algorithms that it should be specified what is logged where and when, in all UML diagrams and text descriptions of algorithm?
See, now you're expanding the scope beyond the original discussion
@Gaska said:I can only wonder what words made you think I write terrible code with shitty error handling.
Funny, I coulda sworn that comment was about the quality my code would be if I wrote it like that…
@flabdablet said:Channeling blakeyrat
-
You're not even arguing about that subject any more - you're arguing about arguing about that subject.
-
See, now you're expanding the scope beyond the original discussion
How are descriptions of algorithms and visual representations of algorithms out of scope of discussion about algorithms?Funny, I coulda sworn that comment was about the quality my code would be if I wrote it like that…
Don't give me that one. It's like if I said I think you're a stinky pile of infant gorrilla shit, and then acted like I never called you that.
-
How are descriptions of algorithms and visual representations of algorithms out of scope of discussion about algorithms?
We were discussing algorithms in code, not in design.
@Gaska said:Don't give me that one.
Why not? I even giftwrapped it for you! Do you know how much good wrapping paper costs‽
-
We were discussing algorithms in code, not in design.
There are algorithms, and there are implementations of algorithms. If we were discussing algorithms, then we weren't discussing the code. If we were discussing implementations, we weren't discussing algorithms. And we were discussing algorithms.Why not? I even giftwrapped it for you! Do you know how much good wrapping paper costs‽
I think you care too much about money.
-
If we were discussing algorithms, then we weren't discussing the code.
Then why was the whole discussion about error handling?
-
Two reasons:
- Algorithms need to handle errors too.
- Earlier, we were indeed discussing implementation.
-
sing syslogd but our very own service that handles all logging, file access, threading and IPC, among other things. Hence, the critical l
Did you idiots just take one thread and plop it down in another wholly unrelated thread? Goddamned.
Oh and look RaceProUK is one of the idiots, so here come the mod warnings again. Woo.
-
Blame @Yamikuronue.
-
The hell? Don't drop arguments here just because they were talking about a discussion they started in this thread in another thread! Jeff digressions into their own threads.
With error returning (in Rust, because C sucks in this regard), it's impossible to miss something because all possible error conditions are right there in the interface!
In any language that allows you to place arbitrary bit patterns in arbitrary memory locations, essentially any language with access to memcpy, this is false. Your tagged union's enum may hold a bit pattern that does not correspond to any of the error codes defined for your enum, and with the proper syntax this may not raise a warning. So you can't guarantee that checking for every defined error will definitely detect every possible error returned.You yourself argued that if something is possible, it will eventually happen. And yet you rely on a feature that can be abused as if no one will ever abuse it.
Or imagine you call a library. Then, after you wrote your code, the library is updated and new error codes are introduced. Do you redo every piece of code that ever depended on this library to account for the new error code?
Even if you know every error you could receive today, you don't know every error code that could be returned in the future.
But this is not just defensive programming, which I absolutely hate, but also paranoid. It's sad it's the only way to be absolutely sure in C++.
It's the only way to be sure in any language, for the reasons I explain above (memcpy and future changes, to name just two). C++ just doesn't lull you into a false sense of security.Like checked exceptions in Java?
I can understand why people who only ever experienced Java's way of doing exceptions might resent therm. Checked exceptions combine the worst of both worlds.
@Gaska, I know you complained before about me not answering to posts not addressed to me. That's not exactly true, but if I see someone else answered essentially what I would have said I don't bother to go "me too". However, in this particular case, I skipped over the jeffed posts. I hope nothing important was there.
-
In any language that allows you to place arbitrary bit patterns in arbitrary memory locations, essentially any language with access to memcpy, this is false.
And Rust isn't one of those languages. Unless you use theunsafekeyword. But then, well... you asked for it.Or imagine you call a library. Then, after you wrote your code, the library is updated and new error codes are introduced. Do you redo every piece of code that ever depended on this library to account for the new error code?
Yes, because if you don't, it won't compile (allmatchstatements must be exhaustive). But usually it's a non-issue because in most places where you check error, you have the "any other error" case.It's the only way to be sure in any language, for the reasons I explain above (memcpy and future changes, to name just two).
Counter-example: Java. There's no way to mess with raw bits (save for FFI calls, but that's cheating), and there's no way to partially construct an object, and you are forced to handle (or declare throwing) every checked exception you might ever encounter in your function. So unless some fucktard throws unchecked exception (which should be reserved for VM use only), you can be absolute certain that everything's gonna be fine.C++ just doesn't lull you into a false sense of security.
I'd say it's the opposite.I can understand why people who only ever experienced Java's way of doing exceptions might resent therm.
I used C++ exceptions years before I learned Java. And I actually think Java way, while overly verbose like everything in Java, is better than C++ way.@Gaska, I know you complained before about me not answering to posts not addressed to me.
It was in a little sarcastic tone.I skipped over the jeffed posts. I hope nothing important was there.
And you'd be right.
-
(which should be reserved for VM use only), you can be absolute certain that everything's gonna be fine.
Wrong. I spent weeks hunting a bug where in 0.1% of cases the entire vm would commit suicide.
I think I closed a nio file access a bit too soon, and it worked in 999/1000 runs.
-
Unless you use the unsafe keyword. But then, well... you asked for it.
So unless some fucktard throws unchecked exception (which should be reserved for VM use only), you can be absolute certain that everything's gonna be fine.
Saying "you're safe UNLESS someone else does something stupid" means you're not safe at all. People will always find a way of doing stupid shit. In your first example, you may be obeying the API contract and checking all the error types. But your coworker may be using the unsafe keyword in his code because he needed to signal a new error and didn't want to add it in the list of errors because that would have required editing every match statement and he is lazy.
You can't rely on other people being reliable. If you could, then Rust's "unsafe" keyword wouldn't need to exist in the first place. Rust is a language founded on the idea that you can't trust other programmers, so the language tries to put hoops between programmers and powerful features. But a determined idiot will not be stopped by hoops.
-
Wrong. I spent weeks hunting a bug where in 0.1% of cases the entire vm would commit suicide. I think I closed a nio file access a bit too soon, and it worked in 999/1000 runs.
Saying "you're safe UNLESS someone else does something stupid" means you're not safe at all.
There are some things nothing can protect us from. When I say "always", I mean "except things I can't do anything about". Compiler bugs, executable code corruption and cosmic rays randomly shifting bits in RAM just happen.
-
Compiler bugs, executable code corruption and cosmic rays randomly shifting bits in RAM just happen.
This was neither. This was me fucking up, and getting shitty feedback from java.
-
whoever wrote the gigabit ethernet driver for the Allwinner SOCs thought it would be a good idea to spam syslog on every packet of VLAN traffic
Seriously -- all you have to do to break it is make the local syslogd send all its messages to a remote syslogd over a VLAN.
