Should _FileListToArray() UNdeclare result array if no files found?

[Mbee]

I've used _FileListToArray() many times, but I've never encountered the curious situation I'm seeing today.  Consider the following code:

#include <Array.au3>
#include <Constants.au3>
#include <File.au3>
;
Global $G_FileList[1]
$G_FileList = _FileListToArray("C:\", "*.txt", $FLTA_FILES)
If @error = 4 Then      ; 4 = No such files
    If IsArray($G_FileList) Then
        MsgBox($MB_OK, "File Array Test", "FileList IS an array, with # " & $G_FileList[0] & " elements")
    Else
        MsgBox($MB_OK, "File Array Test", "FileList is NOT an array!")
    EndIf
EndIf
Exit

When there are no .txt files in the root directory, I see the "NOT an array" message, and thus the _FileListToArray() function seems to actually UN-declare $G_FileList as an array!  Instead, I was expecting it to return an array with only 1 element, and $G_FileList[0] = 0 (although I will grant that the help file does not say that).

So what's the best solution?  Something like the following?

#include <Array.au3>
#include <Constants.au3>
#include <File.au3>
;
Global $G_FileList[1]
$G_FileList = _FileListToArray("C:\", "*.txt", $FLTA_FILES)
If @error = 4 Then      ; 4 = No such files
    If Not IsArray($G_FileList) Then
        Global $G_FileList[1]
        $G_FileList[0] = 0
    EndIf
EndIf
Exit

[jguinch]

Maybe something like this :

#include <Constants.au3>
#include <File.au3>

Local $aEmpty[1] = [0]
Local $aFileList = _FileListToArray("C:\", "*.exe", 0)
If @error = 4 Then $aFileList = $aEmpty

If IsArray($aFileList) Then
    MsgBox($MB_OK, "File Array Test", "FileList IS an array, with # " & $aFileList[0] & " elements")
Else
    MsgBox($MB_OK, "File Array Test", "FileList is NOT an array!")
EndIf

[Mbee]

Thanks, jguinch; that works too, and is neater.

I was just surprised by _FileListToArray()'s behavior...

 

Maybe something like this :

#include <Constants.au3>
#include <File.au3>

Local $aEmpty[1] = [0]
Local $aFileList = _FileListToArray("C:\", "*.exe", 0)
If @error = 4 Then $aFileList = $aEmpty

If IsArray($aFileList) Then
    MsgBox($MB_OK, "File Array Test", "FileList IS an array, with # " & $aFileList[0] & " elements")
Else
    MsgBox($MB_OK, "File Array Test", "FileList is NOT an array!")
EndIf

[Melba23]

Mbee,

This is a similar point to the one made here about _FileReadToArray - and the answer is unsurprisingly the same.

It was a design decision to return a non-array variable if an error occurred from most of the functions which would return an array if successful. If an error is flagged, the user should have errorchecking code to determine what error occurred and how then to proceed - this code can then reset the return variable to whatever is required for the code to continue to run as desired. It is impossible to return a single return value which would suit every case - setting the error macro is the only reasonable thing to do as checking that single item allows each user to proceed as they wish.

And a suggestion of such errorchecking:

; Run function
Local $aFileList = _FileListToArray("C:\", "*.exe", 0)
; If no files found then reset array
If @error = 4 Then Local $aFileList[1] = [0]

Now you can be sure that the variable is an array declared as you want it.

M23

[Mbee]

Thanks, Melba23!

You know, I really am careful to perform due diligence and search the forums before posting a question, but alas, my GoogleFu failed me this time.   I didn't think of performing a blanket search for _FileListToArray in the thread titles, and my pitiful memory is such that I can't recall everything in the change logs and script-breaking docs

However, as I indicated in my OP, I did indeed recognize that the help file entry for _FileListToArray() never promised any defined return value if an error occurred (other than @error), so the documentation certainly was not wrong.  However, would it be hopelessly rude and naive of me to suggest perhaps adding a note in the Remarks section of the help file to explicitly clarify this behavior?  (Just an idea...)

Anyway, the thread you pointed me to explains why I haven't run into this behavior prior to v3.3.12.0.  So now, it's off to check my old scripts for sloppy error handling!

Thanks again!

 

Mbee,

This is a similar point to the one made here about _FileReadToArray - and the answer is unsurprisingly the same.

It was a design decision to return a non-array variable if an error occurred from most of the functions which would return an array if successful. If an error is flagged, the user should have errorchecking code to determine what error occurred and how then to proceed - this code can then reset the return variable to whatever is required for the code to continue to run as desired. It is impossible to return a single return value which would suit every case - setting the error macro is the only reasonable thing to do as checking that single item allows each user to proceed as they wish.

And a suggestion of such errorchecking:

; Run function
Local $aFileList = _FileListToArray("C:\", "*.exe", 0)
; If no files found then reset array
If @error = 4 Then Local $aFileList[1] = [0]

Now you can be sure that the variable is an array declared as you want it.

M23

 

[Melba23]

Mbee,

 

my GoogleFu failed me this time

No problem - I cannot remember all the changes either!

 

the help file entry for _FileListToArray() never promised any defined return value if an error occurred

[...]

perhaps adding a note in the Remarks section of the help file to explicitly clarify this behaviour

I think not - as then we would have to try and make sure that future changes to the function respected the same behaviour. When we rewrite the UDFs (usually to add more functionality) it is difficult enough trying to prevent too many script-breaking changes - defining more closely what happens in error cases would merely be making life much harder for ourselves - or whoever does it in the future.

 

check my old scripts for sloppy error handling!

I would encourage everyone to do this. And perhaps to regard events like this as a opportunity to tighten up the code rather than a problem - I freely admit I had to change some of my old code where I had been less than rigorous.

M23