On Tue, Oct 6, 2020 at 9:33 AM GitBox <[email protected]> wrote: > One thing I've learnt recently, is that exceptions are extremely > expensive, as creating the stack trace is expensive. is this code that is > likely to produce any of "InstantiationException | IllegalAccessException | > InvocationTargetException | NoSuchMethodException" in normal execution? If > yes, we should probably change this and other parts where we use similar > patterns to check first instead of silently catching exceptions. >
Chris is right; Exceptions are incredibly expensive and I have seen instances where a few PLCs are put offline, and the supervisory system goes into a snail pace, either due to excessive exceptions, aggressive retries (without back-off), or both and sometimes with other "oh, didn't think of that" ooopsies. In general, all faults in "real world" should not throw exceptions, and should be viewed as "normality". And unfortunately, Java programmers (even those in this field) tend to not think in "error scenarios" and only in "sunny day paths". Personally, I got over the "exception craze" about 20 years ago, and try to be exception-free. A few tricks to get there; 1. Event driven systems doesn't need "return values", hence a lot less exceptions. Error conditions are different events and subscribers can specialize in the handling. Making a system event driven instead of the request/response type, takes a fair amount of unlearning and mind bending, but worth it. 2. Try to figure out ahead of time if exceptions may be thrown by code I don't control. 3. Don't create nor rethrow exceptions. If in dev/test mode, log an error report containing all possible states that could affect the outcome and then System.exit() as to indicate that there is a serious problem that should not be ignored. In production, the error report is sent to "operations" (containing info to forward to developers if needed) and tries to recover. // Niclas
