Hi Niclas,
I'm definitely in favour of handling errors better. There have been a few
cases I've seen where errors are thrown but the actual error shown doesn't
explain what went wrong, or the error reported is different to the initial
error.
When using the kafka connector (but is probably in the scraper or
pooledconnection somewhere) I noticed that it will try to poll the device
at the same rate as normal (1000ms) when an error occurs. I'm in favour of
making this configurable or using a back-off algorithm.
Kind Regards
Ben
On Tue, Oct 6, 2020 at 5:37 AM Niclas Hedhman wrote:
> On Tue, Oct 6, 2020 at 9:33 AM GitBox 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
>
