Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Cecil Westerhof <Cecil@decebal.nl>
Newsgroups: comp.lang.java.programmer
Subject: Re: How to handle same sanity checks
Date: Fri, 23 Jun 2017 06:48:56 +0200
Organization: Decebal Computing
Lines: 88
Message-ID: <87fuernwav.fsf@munus.decebal.nl>
References: <87o9tgo0a9.fsf@munus.decebal.nl> <oiga3s$jrd$1@dont-email.me> <oih2hb$bad$1@Gaia.teknon.de>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="f007575c907e67c534b3e9f520a75a29"; logging-data="11185"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+U8Jw8Ml0y8qGW0Ew8aiulDavv4OTsmcA="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
X-Homepage: http://www.decebal.nl/
Cancel-Lock: sha1:MpK7C8VEJ3npWtjRFkOYxVJyPUA= sha1:yx/ZDJYgN4gMiOKch2K+FrrqChY=
Xref: csiph.com comp.lang.java.programmer:36702

On Thursday 22 Jun 2017 20:33 CEST, Volker Borchert wrote:

> Eric Sosman wrote:
>> On 6/22/2017 5:10 AM, Cecil Westerhof wrote:
>>> In my code I have several methods that start with:
>>> if ((n < MIN_VAL) || (n > MAX_VAL)) {
>>> throw new InvalidParameterException(String.format(ERROR_N, n));
>>> }
>>>
>>> That is not really DRY.
>>>
>>> I could write a method like:
>>> private void checkN(n) {
>>> if ((n < MIN_VAL) || (n > MAX_VAL)) {
>>> throw new InvalidParameterException(String.format(ERROR_N, n));
>>> }
>>> }
>>>
>>> And then replace all the checks with a call to checkN. But then
>>> the exception is generated in the method checkN instead of the
>>> method that has a wrong parameter. What is the best way to handle
>>> this?
>>
>> Tastes surely vary, but for repetitive checks I favor writing the
>> private internal helper method. Yes, the caller of doItPlease()
>> gets an exception originating from internalSanityCheck() instead,
>> but that shouldn't bother anyone. doItPlease() will be in the stack
>> trace anyhow, even though it's not at the very top.
>
> That can be a problem with some more-or-less-broken logging
> frameworks, and a nuisance if trying to diagnose over the phone.
>
> You can always do something like
>
> 	final InvalidParameterException e
> 	  = new InvalidParameterException(String.format(ERROR_N, n));
> 	final StackTraceElement[] s = e.getStackTrace();
> 	e.setStackTrace(Arrays.copyOfRange(s, 1, s.length));
> 	throw e;

That is a very good idea. I have now:
    private static void checkInRange(final int n,
                                     final int lowLimit,
                                     final int highLimit,
                                     final String message) {
        if ((n < lowLimit) || (n > highLimit)) {
            final InvalidParameterException e =
                new InvalidParameterException(
                    String.format(message, lowLimit, highLimit, n));
            final StackTraceElement[] s = e.getStackTrace();
            e.setStackTrace(Arrays.copyOfRange(s, 1, s.length));
            throw e;
        }
    }

Works like a charm.


I use the function also in another check function. This I solved in
the following way:
    private static void checkInRangeStartEnd(final int start,
                                             final int end,
                                             final int lowLimit,
                                             final int highLimit,
                                             final String messageStart,
                                             final String messageEnd) {
        try {
            checkInRange(start, lowLimit, highLimit, messageStart);
            checkInRange(end,   start,    highLimit, messageEnd);
        } catch (final InvalidParameterException e) {
            final StackTraceElement[] s = e.getStackTrace();
            e.setStackTrace(Arrays.copyOfRange(s, 1, s.length));
            throw e;
        }
    }

The code is now more clear and easier to change, while the stack trace
gives the right information.

Thanks.


Probably I should define a function to modify the stack trace.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof