Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37132 > unrolled thread

Where to put the return

Back to article view | Back to comp.lang.java.programmer

Contents

  Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-11 10:30 +0200
    Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-11 12:24 +0200
    Re: Where to put the return Eric Douglas <e.d.programmer@gmail.com> - 2017-08-11 08:31 -0700
    Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-11 20:33 -0400
      Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 00:27 +0200
        Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 21:41 -0400
          Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 13:15 +0200
        Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 08:12 +0200
          Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 11:10 +0200
            Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 12:54 +0200
              Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 13:46 +0200
                Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 14:10 +0200
                Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 15:35 +0200
                  Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 09:48 -0400
                    Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 23:26 +0200
                      Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 20:01 -0400
                        Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-20 19:30 +0200
                  Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 17:06 +0200
              Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 15:35 +0200
                Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 09:43 -0400
                Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 17:15 +0200
                  Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-21 22:33 +0200
            Re: Where to put the return lewbloch@gmail.com - 2017-08-19 09:20 -0700
              Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-21 22:29 +0200
      Re: Where to put the return Eric Douglas <e.d.programmer@gmail.com> - 2017-08-14 05:11 -0700
    Re: Where to put the return Brixomatic <brixomatic@yahoo.com> - 2017-08-31 19:27 +0200

Page 2 of 2 — ← Prev page 1 [2]

#37289

Robert Klemme <shortcutter@googlemail.com> writes:

> On 19.08.2017 12:54, Cecil Westerhof wrote:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>> On 15.08.2017 08:12, Cecil Westerhof wrote:
>
>>>> 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.
>
> What does that have to do with accessing via index or name?  You are
> talking about changing queries because of changed schema.  But that does
> not necessarily have effects on the layout of the ResultSet.

Because I have seen to many cases where coders did something like:
    SELECT *
    FROM   myTable

You could say that when you use all fields that is not a problem, but
even then I would not use it. But others do.

Also if you use the wrong variable in your getQuery the change you get
an error (what you should want) is bigger with a accessing by name as
by index.


>> 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.
>
> Again, why is it a better practice to avoid accessing columns via index
> instead of name?

See above.


>>> 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.
>
> It's not only about portability.  It is also about conceptual issues.  A
> view is just a view on data.  In relational theory, which is the
> foundation of RDBMS and SQL, a view is just a special subset of the
> data.  (But do not make the mistake to reduce SQL to relational theory - 
> it is actually more.)

I removed the ‘ORDER BY’ in my views. It is handy when using a
database browser, but not that important.

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

[toc] | [prev] | [next] | [standalone]

#37332

On 19.08.2017 17:15, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:

>> What does that have to do with accessing via index or name?  You are
>> talking about changing queries because of changed schema.  But that does
>> not necessarily have effects on the layout of the ResultSet.
> 
> Because I have seen to many cases where coders did something like:
>      SELECT *
>      FROM   myTable
> 
> You could say that when you use all fields that is not a problem, but
> even then I would not use it. But others do.

So you use an even worse habit (actually something commonly recognized 
as "should be avoided altogether") as argument against some completely 
legitimate approach.  I think you have the priorities wrong in this case.

> Also if you use the wrong variable in your getQuery the change you get
> an error (what you should want) is bigger with a accessing by name as
> by index.

Yes.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37290

Constants make sense even if used only once. Seeing the constants at the top of the class definition gives one a quick view of the functionality below, and provides an easily-located maintenance point if one decides later to change the constant value.

I'm highly opposed to defining constants outside the class with which they're semantically associated.

[toc] | [prev] | [next] | [standalone]

#37331

On 19.08.2017 18:20, lewbloch@gmail.com wrote:
> Constants make sense even if used only once. Seeing the constants at
> the top of the class definition gives one a quick view of the
> functionality below,

I am not sure whether a bunch of String constants containing SQL 
statements really conveys the "functionality below".

> and provides an easily-located maintenance point
> if one decides later to change the constant value.

That is correct in the general case.  However, we are talking about SQL 
statements which have close ties to the method that uses it (the method 
needs to extract the correct columns into matching Java types etc.) so 
it is likely that the SQL and the method implementation need to be 
changed in lock step.  I think maintenance in this case is simpler if 
the SQL lives inside the method.

> I'm highly opposed to defining constants outside the class with which
> they're semantically associated.

+1 (Just in case it has not been clear: I am not advocating moving these 
constants out of the class that uses them but inside methods - at least 
for the cases where there is just one using method.)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37219

On Friday, August 11, 2017 at 8:34:07 PM UTC-4, Arne Vajhøj wrote:
> I would go for:
> 
>        private static final String NO_VALUE = "";
>        private static String getOldestUsed() {
>            try (Statement stmt     = sqlite3Conn.createStatement();
>                ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>                if (rsOldest.next()) {
>                    return rsOldest.getString("used");
>                } else {
>                    return NO_VALUE;
> 	      }
>            } catch (SQLException e) {
>                giveError("Error in displayOldestUsed");
>                e.printStackTrace();
>                fatalError("");
>                return NO_VALUE;
>            }
>        }
> 
> But there are many acceptable ways of writing this.
> 
> Arne

I'm not sure what exceptions you're trying to catch here.  As Robert said it's most likely best to do something different with the catch clause, whether you simply throw the exception, or if for some reason it's not allowed to crash just return ERROR_VALUE;

I think Eclipse has a warning that says your else is irrelevant.  You can always leave that verb out if the condition ends with a return.
     ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) { 
     if (rsOldest.next()) { 
          return rsOldest.getString("used"); 
     } 
     return NO_VALUE; 

[toc] | [prev] | [next] | [standalone]

#37369

In article <87zib6zeup.fsf@munus.decebal.nl>, Cecil Westerhof 
(Cecil@decebal.nl) says...
> 
> I have the following function:
>     private static String getOldestUsed() {
>         String oldestUsed = "";
> 
>         try (Statement stmt     = sqlite3Conn.createStatement();
>              ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>             if (rsOldest.next()) {
>                 oldestUsed = rsOldest.getString("used");
>             }
>         } catch (SQLException e) {
>             giveError("Error in displayOldestUsed");
>             e.printStackTrace();
>             fatalError("");
>         }
>         return oldestUsed;
>     }
> 
> Often I see the return in the try block. But personally I prefer it
> this way. Is there a preferred way, or are both ways acceptable?

I personally like to keep the meat of the method together and variable 
scope small. 

I also don't think you're handling the case "no result" very well. For a 
single result, an optional return value would probably be better. This 
way the caller can handle the default case (and the caller probably 
knows better what default is appropriate) and your error handling can be 
more abstract.

So this would probably be my version, which I also find more readable:

    private static Optional<String> getOldestUsed() {
         try (Statement stmt    = sqlite3Conn.createStatement();         
             ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
             return rsOldest.next() ? Optional.of(rsOldest.getString());
                                    : Optional.empty();
         } catch (SQLException e) {
             return failOptionalMethod("Database error", e);
         }
     }

     private static <T> Optional<T> failOptionalMethod(String m, 
Throwable t){
       //1. optionally show an error to the user that includes a 
       // stacktrace that can be sent/copied to the support/bug tracker.
       //2. log the error for your own statistics
	return Optional.empty();
     }


Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web