[ ??? ] FileOpen() Exception

[nnnik]

Yeah but AutoHotkey returns an error as soon as it detects that the handle it receives is false.
In the description to GetStdHandle:

If the function fails, the return value is INVALID_HANDLE_VALUE. To get extended error information, call GetLastError.

If an application does not have associated standard handles, such as a service running on an interactive desktop, and has not redirected them, the return value is NULL.

But there is nothing in there that says anything about GetLastError.
In fact GetLastError returns null for me:

Code: Select all

fHandle := DllCall("GetStdHandle", "int", -10, "ptr")
Msgbox fHandle " " A_LastError ;add % for v1 its the same result

In the code throwing the exception lexikos uses:

Code: Select all

aResultToken.SetExitResult(g_script.ThrowWin32Exception(GetLastError()));

sololy relying on GetLastError to describe the error.
Im not sure how that results in a different error message than yours on my PC though.

[nnnik]

In fact to me it seems like AutoHotkey doesn't handle the INVALID_HANDLE case of GetStdHandle either.

[kczx3]

V1 just returns 0 and continues onward for fileopen("*", "W"). I don't know the proper course of action to handle these. But it would seem something better is necessary to properly inform the user.

[_3D_]

The base of ALL again: OpenFile function
And brief:Return value
If the function succeeds, the return value specifies a file handle to use when performing file I/O. To close the file, call the CloseHandle function using this handle.
If the function fails, the return value is HFILE_ERROR. To get extended error information, call GetLastError.
Simple and working from years.

BTW

Code: Select all

DllCall("AllocConsole")
stdin  := FileOpen("*", "r `n")

Return FileObject without Handle.

The only reason, that I see, in Object instead Handle is to encapsulate all functions and data that is needed to manipulate files into one. Even this making exceptions for whatever is extremely annoying. Most things must work like just in life.

By making things more complicated, they become less comprehensible.

[nnnik]

You are very much still free to use the DllCall Version.
I don't see the problem considering your definition of keep it stupid simple.

[just me]

For * and ** it might help to change TextIO.cpp, e.g.

Code: Select all

//
// TextFile
//
bool TextFile::_Open(LPCTSTR aFileSpec, DWORD &aFlags)
{
      ...
      ...
      if (nStdHandle) // It was * or ** and not something invalid like *Somefile.
      {
         HANDLE hstd = GetStdHandle(nStdHandle);
         if (hstd == NULL) // || !DuplicateHandle(GetCurrentProcess(), hstd, GetCurrentProcess(), &hstd, 0, FALSE, DUPLICATE_SAME_ACCESS))
         {
            hstd = INVALID_HANDLE_VALUE;
            SetLastError(ERROR_INVALID_HANDLE); // as an example
         }
         aFlags = (aFlags & ~ACCESS_MODE_MASK) | USEHANDLE; // Avoid calling CloseHandle(), since we don't own it.
         mFile = hstd; // Only now that we know it's not NULL.
         return mFile != INVALID_HANDLE_VALUE;
      }
      // For any case not handled above, such as WRITE|READ combined or *** or *Somefile,
      // it should be detected as an error below by CreateFile() failing (or if not, it's
      // somehow valid and should not be treated as an error).
      ...
      ...
}

IMO, it's related to v1 and v2.

[Helgef]

I am aware from the next code:

Code: Select all

comm:= FileOpen('\\.\COM1', 'w') ;The system cannot find the file specified.
comm.WriteLine('Hello world')
comm.Close()

So why do you want the error on the second line and not on the first? What if the second line doesn't occur until much later (away) from the first line? I don't expect you to answer that.

Cheers.

ot

The error message...
Perhaps Script::ThrowWin32Exception could print something else if the error code is 0, but I don't think it is necessary to change it really, windows sets the error code. Perhaps in the future the exception type will better indicate what the error is.

[_3D_]

So why do you want the error on the second line and not on the first? What if the second line doesn't occur until much later (away) from the first line? I don't expect you to answer that.

Cheers.

Actually I don't want any errors in any order. I just need a simple method that open a file, and a simple method that keep (sign or flag) for that file.
When FileOpen() throw exception instead returning "" I lose "sign" that show me (in all threads) what happens with the output (in this case). So code must be like this:

Code: Select all

try file:= FileOpen('filename.ext','attr')
catch
	file:= ''

Now all that can "see" variable "file" can "decide" what to do. So, when weighing the pros and cons - exception not in pros.
Here I hear a voices about "speed" - but let check:
1. AHK call windows API function that return HANDLE or 0 (there no alternatives).
2. AHK check if HANDLE and generate FileObject or throw exception.
VS
1. AHK call windows API function that return HANDLE or 0.
So, where the speed is?

[nnnik]

Its not about speed its about finding bugs faster and more easily.
Im pretty sure at this point that you just try to argue to change the language so that the code structure that you already made makes sense - Im sorry though, the code structure you made doesnt suit v2.
Changing it back just so that people might have an easier time using the same code structure they used from v1.

You mention one case where your behavior is beneficial but dont even mention the downsides of your design.
The downsides are that FileOpen would be completely inconsistent with any kind of other command which also throws as soon as there is any kind of bug.
And that arguably the biggest problem for newbies is that the language doesnt tell you when something goes wrong.
Its also one of the biggest problems for advanced coders in longer code where bugs just dont show themselves.

AHK doesn't even return any handle - it returns an object containing the handle.

I actually dont see this topic going anywhere new in the last 5-6 posts.
So unless someone has something to add I will probably close it in the near future.