Jump to content
Sign in to follow this  
mrider

DriveGetDrive API error for proper type - why?

Recommended Posts

mrider

Sorry for the terse topic title, I'll happy to edit it so it sounds less confrontational if anyone has any suggestions. :)

I'm wondering if it might be better if DriveGetDrive behaved a bit differently.  On my computer, the code below fails at "REMOVABLE", since I don't have any removable drives.  My question is not, how do I keep it from failing.  My question is why does asking for something legitimate - that I just happen to not have - considered an error?  Wouldn't it make more sense to simply return the equivalent of

$array[1] = [0] - and reserve the error for something truly wrong?  Like DriveGetDrive("A_Totally_BOGUS_VALUE")?

PrintDrive("ALL")
PrintDrive("CDROM")
PrintDrive("REMOVABLE")
PrintDrive("FIXED")
PrintDrive("NETWORK")
PrintDrive("RAMDISK")
PrintDrive("UNKNOWN")

Func PrintDrivesForName($drive)
    ConsoleWrite($drive & " : ")
    Local $drives = DriveGetDrive($drive)
    For $i = 1 To $drives[0]
        ConsoleWrite($drives[$i] & @TAB)
    Next
    ConsoleWrite(@LF)
EndFunc

The problem is that it greatly complicates handling the case of "you don't have one of those" - which is distinct from "you asked for something totally incorrect".

 

Please note once again, my question is not how do I keep the code from failing - I can figure out how to add an error check. 

My quesiton is: what use-case makes the current behavior desirable over simply returning an array with zero as the first and only element?  (Except in the case where the code genuinely asks for something bogus of course)


How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
Melba23

mrider,

Good question. I will move the thread to the more suitable "Developer Chat" section. :)

M23


Public_Domain.png.2d871819fcb9957cf44f4514551a2935.png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind

Open spoiler to see my UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites
mrider

Thanks!


How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
BrewManNH

It's not failing, you don't check for an error, your code is what is failing.

If you use DriveGetDrive with "Removable" and you have no removable drives, the function returns @error set to 1, checking to see if @error is anything other than zero would prevent the array error message.


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites
jpm

I understand you like a return array with the first value as 0 but checking error whatever it is return as, is a fundamental habit.

I don't think Jon will change the error return for this function

Share this post


Link to post
Share on other sites
mrider

 

 I would imagine it's because it's trivial to implement.

I suppose. 

However, it seems to me like it would be trivial to alter the API once, and then let everyone get the benefit of that change.  The problem is that as it stands, there are probably hundreds of scripts out there that ignore the error message that they know can't happen, but really can.  How often do you check @error for e.g. CDROM?  The computer always has a CDROM after all.  But what if it doesn't?

One of the beauties of AutoIt is that one can quickly write code that has a relatively low bug count due to the fact that AutoIt tolerates inexactness well.  For example:

Local $l = "5"

Local $r = "10"

ConsoleWrite(($l * $r) & @LF)

 

Most programming languages would fall on their face immediately on that code.  AutoIt would be considerably less pleasant to use if that threw an error because $l and $r started life as Strings (cough Python cough).

 

 

 

It's not failing, you don't check for an error, your code is what is failing.

That's not what I asked.  My question is - why does it set an error at all?  There's nothing wrong with asking about "REMOVABLE" other than the fact that I don't have any.  It seems to me that the error would be better served replying to a request for something outside the allowed types.

Edited by mrider

How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
mrider

 

I understand you like a return array with the first value as 0 but checking error whatever it is return as, is a fundamental habit.

I don't think Jon will change the error return for this function

 

Fair enough. :)


How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
mrider

Knowing that this will never come to pass, I'd still like to leave this parting shot.  Compare the two versions of the same subroutine - one where the API is altered versus as it is now (and thank you to all for reading and replying to my post):

; Returning a zero array
Func PrintDrivesForName($drive)
    Local $drives = DriveGetDrive($drive)
    ConsoleWrite($drive & " : ")
    If @error Then
        ConsoleWrite($drive & " is not a valid designation")
    Else
        For $i = 1 To $drives[0]
            ConsoleWrite($drives[$i] & @TAB)
        Next
    EndIf
    ConsoleWrite(@LF)
EndFunc
; As it is now
Func PrintDrivesForName($drive)
    Local $drive_types[7] = [ _
        "ALL", "CDROM", "REMOVABLE", "FIXED", "NETWORK", "RAMDISK", "UNKNOWN"]
    Local $drives = DriveGetDrive($drive)
    ConsoleWrite($drive & " : ")
    If @error Then
        Local $found = False
        For $i = 0 To UBound($drive_types) - 1
            If $drive = $drive_types[$i] Then
                $found = True
                ExitLoop
            EndIf
        Next
        If Not $found Then
            ConsoleWrite($drive & " is not a valid designation")
        EndIf
    Else
        For $i = 1 To $drives[0]
            ConsoleWrite($drives[$i] & @TAB)
        Next
    EndIf
    ConsoleWrite(@LF)
EndFunc
Edited by mrider

How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
BrewManNH

 

That's not what I asked.  My question is - why does it set an error at all?  There's nothing wrong with asking about "REMOVABLE" other than the fact that I don't have any.  It seems to me that the error would be better served replying to a request for something outside the allowed types.

It sets an error because you created an error in looking for something that doesn't exist. What would you like it to return? Searching for something that doesn't exist is an error condition in every language I can think of.

 

Use _FileListToArray as an example, search for a folder that doesn't exist, you'll get an error condition, search for a file that doesn't exist, you get an error condition. This is consistent with practically every function.


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites
BrewManNH

 

Knowing that this will never come to pass, I'd still like to leave this parting shot.  Compare the two versions of the same subroutine - one where the API is altered versus as it is now (and thank you to all for reading and replying to my post):

; Returning a zero array
Func PrintDrivesForName($drive)
    Local $drives = DriveGetDrive($drive)
    ConsoleWrite($drive & " : ")
    If @error Then
        ConsoleWrite($drive & " is not a valid designation")
    Else
        For $i = 1 To $drives[0]
            ConsoleWrite($drives[$i] & @TAB)
        Next
    EndIf
    ConsoleWrite(@LF)
EndFunc
; As it is now
Func PrintDrivesForName($drive)
    Local $drives = DriveGetDrive($drive)
    ConsoleWrite($drive & " : ")
    If @error Then
        Local $found = False
        For $i = 0 To UBound($drive_types) - 1
            If $drive = $drive_types[$i] Then
                $found = True
                ExitLoop
            EndIf
        Next
        If Not $found Then
            ConsoleWrite($drive & " is not a valid designation")
        EndIf
    Else
        For $i = 1 To $drives[0]
            ConsoleWrite($drives[$i] & @TAB)
        Next
    EndIf
    ConsoleWrite(@LF)
EndFunc

Your first example doesn't return anything,and it's the proper way to use the function as written. The second one also doesn't return anything, but isn't how the function works as is now either.


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites
wraithdu

I think a better compromise might be simply an additional @error return value: 1 = no drives found, 2 = invalid drive specification. It's non-script breaking and adds your functionality. I say non-script breaking, because it's just as valid in the current function to test if the return is an array or not with IsArray().

PS, neither of your scripts will work correctly as written, as you're testing @error after ConsoleWrite() which will reset the @error value.

Edited by wraithdu

Share this post


Link to post
Share on other sites
mrider

Oh well.  Just something I noticed and thought could be improved.  Never mind. :)

 

 

PS, neither of your scripts will work correctly as written, as you're testing @error after ConsoleWrite() which will reset the @error value.

 

You're right of course.  I quickly typed that without testing and didn't notice that problem.

Edited by mrider

How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
JohnOne

There is nothing stopping you officially requesting this.

There's some sort of feature request place somewhere, sorry I don't know where to find it.

EDIT:

Think it's the bugtracker up the top there.

Edited by JohnOne

AutoIt Absolute Beginners    Require a serial    Pause Script    Video Tutorials by Morthawt   ipify 

Monkey's are, like, natures humans.

Share this post


Link to post
Share on other sites
mrider

The reason I came up with this (admittedly dumb) idea in the first place is that I have a ton of scripts where I have a simple text field where I ask for a "starting directory" before performing some simple operation.  Typically I'll have a button titled something along the lines of "Select Directory" next to it that brings up a folder selection dialog.  I typically write the code to cleanly handle typed in directories as well as e.g. "ALL" or "NETWORK". 

It seemed like having an easy and clean way to deal with the difference between e.g. "NETWORK" versus "NETOWRK" would be nice (e.g. "you don't have any of those" as opposed to "hey dummy, check your spelling") would be helpful.

 

Wraithdu brought up an excellent point that never occurred to me - namely that people might be using IsArray() on the return of DriveGetDrive to switch on the results.  So the alteration I thought of would break scripts and would be bad.

I kind of like the idea of returning a different error for "you asked for a bogus name" as opposed to "you don't have any of those" though.  It doesn't break anything, and greatly simplifies error handling.  So I might try that as a suggestion.  The only scripts it would break would be ones where coders have already written "if error = 1" as opposed to "if error"

Edited by mrider

How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
mrider

 

I don't think what wraithdu suggested would break any scripts.

Agreed.  The thought I had would break scripts.  wraithdu's suggestion wouldn't. 

 

In fact, I turned in a feature request asking if the devs could alter the @error value from DriveGetDrive function to differentiate between using a term that is incorrect versus asking for something that's correct but happens to have no results.  http://www.autoitscript.com/trac/autoit/ticket/2483

 

 

Also, are you aware of FileSelectFolder() function?

That's precisely what I use.  Generally speaking, I tend to have a moderately large text box where one can type the path, and next to it I have a button that brings up the folder selector from FileSelectFolder function.  I don't like having nothing but a GUI, I can type "D:Data" faster than I can click the button and navigate to the folder in question.  On the other hand, I like being able to search for "D:DataFooBarBaz" when required.

As I say, I try to handle having the user type in e.g. "ALL" elegantly.


How's my riding? Dial 1-800-Wait-There

Trying to use a computer with McAfee installed is like trying to read a book at a rock concert.

Share this post


Link to post
Share on other sites
wraithdu

The additional @error return wouldn't patently be script breaking, however there are circumstances where it would be. Since the current docs specify an @error return of '1', versus a more general 'non-zero' return, it is acceptable for a dev to test 'If @error = 1 Then'. If a dev expects that to test any error condition, then yes, the addition of another @error return value would be script breaking for them.

But I think it is much more common for devs to test the more generic 'If @error Then'. So the impact would be minor, and documented of course.

Share this post


Link to post
Share on other sites
jpm

Small remark,

I did not change in all place set @error to 1 to set @error to non-zero but should have do it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×