nathanwbrei
commented
1 year ago That's a good catch! (no pun intended) I've heard so many contradictory things about the safety and performance of C++ exceptions that I don't trust anything except experimental evidence. It's great actually having said evidence for once.
I'm really not a fan of using exceptions for flow control whether they are performant or not. I'd be quite happy to return a status enum even though it'll be a breaking change. I already wrote JBlockedEventSource like that, and we convert the exceptions back into error codes under the hood, so it would amount to a pleasant reduction of complexity for all parties involved.
The important thing is keeping a unique status enum for each particular function, and not being tempted to have a global error code, because otherwise nobody knows which codes are valid to return, which are necessary to check for, or whether a code indicates a fatal condition vs a recoverable one.
I noticed while working on some JANA2 plugins to replay data from the tridas beam test that it was slower than expected. This turned out to be due to a typo in a factory tag. This particular plugin was written to be tolerant of the factory not existing so it was catching and ignoring the exception for the missing factory.
I don't have time to investigate now, but just dropping a note here to check if the exception itself is the cause for the slowdown (by about a factor of 7 in this case) or something else.
Note, if the exception itself is very slow then we may need to revisit the exceptions used for flow control in the "TRY_AGAIN" situations for networked event sources.