Fix dtype getters
Author: sgugger
Pull request: yes

# What does this PR do?

This is a hotfix for #17649 which rely on the old behavior when there is no floating point parameters. I think some empty parameter generators are responsible but I can't understand why the old code works. I will dig more into it but for now we need something to fix all uses of (at least) BERT in examples as for now
```
python examples/pytorch/text-classification/run_glue.py --model_name_or_path bert-base-cased --task_name mrpc --output_dir ~/tmp/test-glue/ --do_train
```
fails (not after this PR).

Fixes #17649

Comments:
_The documentation is not available anymore as the PR was closed or merged._

@stas00 Merging this without waiting for you to wake up to have the examples running again. Once I've investigated more, I'll open a new PR with a (hopefully) better fix and a new test (since we should have caught that issue on the CI).

Thank you @sgugger ! You are faster before I even realized the scheduled CI is broken ❤️ 

This is very mysterious, almost undefined behavior by python.

So the error is:
> UnboundLocalError: local variable 't' referenced before assignment

so then the loop variable is not visible in the `else` struct - that behavior is not defined by the python documentation, 
https://docs.python.org/3/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

A quick test shows that it is visible:
```
In [1]: for i in [1,2]:
   ...:     print(i)
   ...: else:
   ...:     print(i)
   ...:
1
2
2
```

Unless the loop generator returned nothing, and thus `i` was never initialized:

```
In [1]: for i in []:
   ...:     print(i)
   ...: else:
   ...:     print(i)
NameError: name 'i' is not defined
```

but if  `parameter.parameters()` was an empty generator, your fix `next(parameter.parameters())` should have failed too.

Very mysterious.

But in any case, eventually we need to add a test that covers that use case. Most likely none of the existing tests, including the one I added covered the `else` branch and thus we missed it.

and since you're no longer relying on the loop's local variable we probably should drop `else` as this no longer seems right.

Thank you all for this PR!

@stas00  Actually when generator is empty, `next()` throws `StopIteration` which is already handled by try-except statement, that's why this PR makes it work properly.

ah, I see, thank for highlighting what I missed, @KeremZaman! that explains it!

so @sgugger the other 2 cases can be reverted to how they were before this PR, since we already have the last entry.

and really this PR can be just to augment:

```
- except StopIteration:
+ except StopIteration, UnboundLocalError:
```

but it's totally fine to leave things as they were merged. except someone is bound to try to fix it down the road.

I propose a much cleaner and more readable solution that requires no try/except at all, POC:

```
if len(parameter.parameters()) > 0:
    for loop ...
else:
    nn.DataParallel compatibility in PyTorch 1.5 code
```

Agreed. Like I said, I will dive deeper this afternoon and make another PR for this today or Monday :-)