Home > Software design >  Does or DID Win32 CopyFile(W) ever raise a (SEH) exception?
Does or DID Win32 CopyFile(W) ever raise a (SEH) exception?

Time:02-04

The Windows API CopyFile function is rather straightforward:

BOOL CopyFileW(
  [in] LPCWSTR lpExistingFileName,
  [in] LPCWSTR lpNewFileName,
  [in] BOOL    bFailIfExists
);

...

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

However, I found this gem in our C source code, dating back to Oct / 2006:

try {       //Exception, if the file already exists and is write protected
    bCopyOK = CopyFile(csSourceFile, csDestinationFile, bFailIfExists);
} catch (...) { 
    bCopyOK = FALSE;
}

I even found the old ticket title (of course without details): "function 'CopyFile' throws Exception if Destination is write protected, catch Exception" :-)

Even today we still compile with /EHa, so this would have caught any SEH exceptions raised.

Now, at this point in time we would've been using Visual Studio 6 on Windows XP, and that one had all kinds of quirks, but still: I have a hard time imagining this function ever raising an exception (apart from invalid/null parameters and such).

CodePudding user response:

Does or DID Win32 CopyFile(W) ever raise a (SEH) exception?

NO.

at first not exist SEH exceptions at all. SEH this is type of exception handler but not type of exception. another type of handlers (not exceptions) is VEH.

exception can be raised or via invoke RaiseException /RtlRaiseException / ZwRaiseException or by CPU. of course CPU exception alwas can be raised (in case lpExistingFileName or lpNewFileName for instanse point to invalid memory ) but CopyFileW never call RaiseException - by fact and by documentation.

//Exception, if the file already exists and is write protected

so in what problem ? create write protected file lpNewFileName and call CopyFile and test result. will be exception or error code returned

CodePudding user response:

// Self answer, with historical perspective.

It is not documented to throw exceptions, as is apparent from the current docs linked above.

Both the other answer and also, e.g. Do DeleteFile() Or CopyFile() throw exceptions? quite definitely assert that there should be no exception being raised.

However, as is mentioned in comments:

Very few API calls are documented to raise SEH exceptions, but that doesn't mean that they won't, or prevent SEH exceptions raised in foreign code from passing through.

and in the linked question:

comment: ... Some odds that getting rid of the installed anti-malware product can rescue it, ymmv. ...

A: It was ... corporate info safety system, anti-malware like product.

It is very well possible that the original developer could actually reproduce this behavior on his machine, and swallowing the error "fixed" it well enough back then.

Things have improved since then. Given that no reproduction is possible in current code, and given that this only works with /EHa anyways, the try-catch is a candidate for cleanup.

  • Related