Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Cecil Westerhof Newsgroups: comp.lang.java.programmer Subject: Re: Where to put the return Date: Sat, 19 Aug 2017 12:54:21 +0200 Organization: Decebal Computing Lines: 122 Message-ID: <87bmnbj09u.fsf@munus.decebal.nl> References: <87zib6zeup.fsf@munus.decebal.nl> <87y3qlnyvj.fsf@munus.decebal.nl> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="3820b20d39a2e7728f71dbc5da182e9b"; logging-data="7824"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2cxC92JAhMz8v0/T65wXKRXmBdJzQlgE=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Homepage: http://www.decebal.nl/ Cancel-Lock: sha1:KVWhtXfJ6i0QMHaBlf4mtfS6KTk= sha1:LRfVuNpkjNHQJE9Pe3xbVUgydCU= Xref: csiph.com comp.lang.java.programmer:37281 Robert Klemme writes: > On 15.08.2017 08:12, Cecil Westerhof wrote: >> Robert Klemme writes: >> >>> Btw. I'd rather throw in catch than return a special value. That is >>> cleaner and does not break if the special value actually occurs in the >>> database. >> >> I agree. But that is what the call to fatalError does: it cleans up >> resources and exits the program. But I changed that to just let the >> SQLException fire: >> private static String getOldestUsed() throws SQLException { >> String oldestUsed = ""; >> >> try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) { >> if (rsOldest.next()) { >> oldestUsed = rsOldest.getString("used"); >> } >> } >> return oldestUsed; >> } > > I'd rather > > private static String getOldestUsed() throws SQLException { > try (final SQLResultSet rs = sqlite3Conn.executeQuery(OLDEST_USED)) { > if (rs.next()) { > return rs.getString("used"); > } > } > > return ""; > } > > > But religious wars have been fought about additional returns inside > methods. To me this reads easier because you see the fallback return > value immediately and you can recognize immediately what value is > returned. In this smallish example it probably does not make a > difference though. I will think about it. > Btw. SQL statements when used like this tend to be specific to the > method. So by inserting the SQL directly in the method instead of in a > constant the reader has more information at hand and can quicker > understand the logic. Constants make much more more sense if the SQL is > actually reused in different locations. I find it handy to have all the definitions in one place. But again: it does not hurt to think about it. >>> And another remark: we do not see the SQL but in this case I would make >>> sure that OLDEST_USED actually returns exactly one column and access >>> that via index instead of name. IIRC this tends to be slightly quicker. >>> But it may be just an old habit of mine. >> >> One of the things I do is make sure you cannot use index. I find that >> a very bad habit. > > Why? I have to often seen that a database definition changed and there was a big problem with the code, because a lot of queries had to be changed. I agree that with the kind of programs my wrapper will be used it probably is mot a big deal, but it does not hurt to make people learn to use better practises. >> Also when you give the wrong query, but it gives one >> column back, you have a hard to find bug. > > If the value happens to be of the same type as the expected one, yes. > But since I would insert the query text in the method (see above) that > is less of an issue. When using the query text, yes. When using a constant no. And getXXX will be used add places where there is used a constant. >> The SQL used: >> SELECT used >> FROM usedProverbs >> LIMIT 1 >> >> I defined usedProverbs as a sorted view (on proverbs), that is why >> there is no SORT BY. > > Sorted view is another thing I would not do. I am not sure that is even > a supported features across most databases. It does have issues - > technical and conceptual. In this case it is on a SQLite3 database which does have it and I think it very unlikely to change. But you are right: when I want the code to be portable I should not use this, or add a comment to the code. > With the SQL given the reader does not have a chance to identify the > full criteria that select the value "used" because you do not see the > sorting criteria. I would rather put the "ORDER BY" into the query. (Or > make it a query with "MIN" depending on schema.) At least prepending MIN_ would be a good idea. > You can read a lot on > the issues of sorting a view, for example here: > > https://dba.stackexchange.com/questions/21434/why-does-order-by-not-belong-in-a-view/ I will evaluate that. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof