Fix parameter meta data with whitespace characters

[xiangyushawn]

new PR equivalent to #351 which fixes #344

[codecov-io]

Codecov Report

Merging #371 into dev will decrease coverage by 0.16%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##                dev     #371      +/-   ##
============================================
- Coverage     40.16%   39.99%   -0.17%     
+ Complexity     1892     1883       -9     
============================================
  Files           107      107              
  Lines         24482    24511      +29     
  Branches       4038     4046       +8     
============================================
- Hits           9833     9804      -29     
- Misses        12815    12870      +55     
- Partials       1834     1837       +3

Flag	Coverage Δ	Complexity Δ
#JDBC41	39.83% <0%> (-0.22%)	1874 <0> (-9)
#JDBC42	39.9% <0%> (-0.11%)	1878 <0> (-7)

Impacted Files	Coverage Δ	Complexity Δ
...oft/sqlserver/jdbc/SQLServerParameterMetaData.java	23.81% <0%> (-1.71%)	30 <0> (ø)
...om/microsoft/sqlserver/jdbc/ReaderInputStream.java	44.94% <0%> (-3.38%)	16% <0%> (-1%)
src/main/java/microsoft/sql/DateTimeOffset.java	37.14% <0%> (-2.86%)	8% <0%> (-2%)
...om/microsoft/sqlserver/jdbc/SimpleInputStream.java	47.4% <0%> (-1.49%)	9% <0%> (-1%)
...m/microsoft/sqlserver/jdbc/SQLServerResultSet.java	26.86% <0%> (-0.55%)	184% <0%> (-4%)
...m/microsoft/sqlserver/jdbc/SQLServerStatement.java	59.06% <0%> (-0.31%)	129% <0%> (-1%)
...om/microsoft/sqlserver/jdbc/SQLServerBulkCopy.java	49.21% <0%> (-0.29%)	210% <0%> (ø)
...rc/main/java/com/microsoft/sqlserver/jdbc/dtv.java	39.45% <0%> (-0.21%)	0% <0%> (ø)
...in/java/com/microsoft/sqlserver/jdbc/IOBuffer.java	44.8% <0%> (-0.13%)	0% <0%> (ø)
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3bd68b5...562c390. Read the comment docs.

[ulvii]

Do we need a null check here?

[xiangyushawn]

In this case, if we look at the caller of the method, the variable will never be null since it's a token returned from StringTokenizer (instead of returning null, NoSuchElementException will be thrown if there are no more tokens in this tokenizer).

You are right, it's a good practice to always check for null.

[ulvii]

Yes, currently firstToken cannot be null, but there might be more caller methods in the future :)

[xiangyushawn]

Yes, you are right :) Done