301–310 of 516 posts
> As illustrational example consider this small code fragment: Consider this crap small code fragment. Any function that returns void is almost certainly wrong.
You are right. That's why in good old languages they were called 'procedures.'
Earlier quoted context omitted.
Enlighten us, please
Any function that does not return a value must have a side effect, else why call it. Calling functions that have side effects (and particularly don't indicate if the side effect was succesful), is not a great idea.
Even things like I/O or dynamic memory allocation have side effects. So while FP has some great ideas implemented at scale (first class functions and MapReduce perhaps the most well-known), they don't seem very useful by themselves.
EDIT: I'm not objecting to the idea "functions should return information," I'm objecting to the idea that side effects are "not a great idea."
Earlier quoted context omitted.
This would mean that attempting to open a file that doesn't exist shouldn't throw an exception. But that is exactly what it does in the standard libraries of many languages with exceptions.
Not in C++ I believe ?
That's why we disable exceptions in video games.
Earlier quoted context omitted.
I am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems. Just think about this: If you have a 100 cores, and 1% of your…
I've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it. I would suggest you need to address that 1% of failing tasks and determine what the issue is,…
Now, in this thread, exceptions are supposed to be used rarely. I don't see the difference between an exception and Rust/Go's `panic`. If the error is rare enough, then chances are you cannot gracefully recover. If the error isn't rare; then why are you using exceptions for control flow?
If not exception, then how to fail constructor?
Don't write constructors that can fail unless it is failure that would be appropriate to crash for. That works out a lot better than it might naively sound. It is hard for people to reason about the possibility of constructors/destructors failing, so actually rather nice to just forbid it.
Earlier quoted context omitted.
Any function that does not return a value must have a side effect, else why call it. Calling functions that have side effects (and particularly don't indicate if the side effect was succesful), is not a great idea.
Are there any software projects of substantial scale that are purely FP? Even things like I/O or dynamic memory allocation have side effects. So while FP has some great ideas implemented at scale (first class functions and MapReduce perhaps the most well-known), they don't seem very useful by themselves. EDIT: I'm not objecting to the idea "functions should return information," I'm objecting to the idea that side eff…
BTW, I am basically a C++ programmer, not some functional maniac. But whenever I see a void return type, I think something is wrong.
Earlier quoted context omitted.
Yes, that's right, as static type checks generally are. However, the C++ performance issues are unrelated to whether exceptions are statically and/or runtime checked. Furthermore, Java exceptions are not particularly efficient, in particular because they collect the current stack trace on creation by default, which is a relatively expensive operation.
I thought you could tune away the trace on creation behavior. Regardless, I'd be interested in seeing if this is a performance bottleneck. I'd guess it is only relevant on dataset processing. Closer you are to a place that legitimately can toss to a user, more likely you are to not care? That is, if the common case of an exception is to stop and ask for intervention, is this a concern at all?
You can when you implement your own exception type, but not in general (and doing so would break too many things).
Exceptions are thrown and caught quite frequently in Java for "expected" cases, for example when attempting to parse a number from a string which is not a valid number. It's generally not a performance problem, and stack trace collection is probably heavily optimized in the JVM. Nevertheless, it's certainly still a lot slower than C++ single-threaded exceptions. You have to realize that even a factor of 100 slower may be unnoticeable for many use cases, because so much else is going on in the application.
Wouldn’t changing the global mutex into a read/write be a simple way to fix things? Shared libraries changing the exception table at the same time as exceptions being thrown seems rare. Might also be fixable in an API-preserving way… Edit: nope. This idea is discussed later in the paper (not fully ruled out but the answer may still require ABI changes for more subtle reasons)
Earlier quoted context omitted.
I am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems. Just think about this: If you have a 100 cores, and 1% of your…
I've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it. I would suggest you need to address that 1% of failing tasks and determine what the issue is,…