plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Cost of Exceptions [was: chrisdutz commented on a change in pull request #192: Refactor Field Handler Classes]
Date Tue, 06 Oct 2020 09:27:24 GMT
On Tue, Oct 6, 2020 at 9:33 AM GitBox <git@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message