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

Question

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).

Side Note: Aha: Maybe it was hooked back then, like mentioned here https://stackoverflow.com/questions/51951586/the-copy-task-failed-unexpectedly — Martin Ba, Feb 03 '23 at 09:44
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. The best way to handle this is to let the process terminate, and set up WER to collect diagnostic information. Any attempt to suppress the exception will just produce an application that spuriously fails, with no one ever finding out what's behind any of this. — IInspectable, Feb 03 '23 at 10:10
`CopyFile` never raise software exception ( SEH - this is not type of execption but type of exception handler). can be only hardware exception, if file names point to invalid memory location. but this can not be habdled via try/catch(...) but only via __try/__except. the code snippet wrong and senseless — RbMm, Feb 03 '23 at 10:21
@RbMm The [`/EHa`](https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model) compiler flag allows `catch(...)` to catch both C++ and structured exceptions. — IInspectable, Feb 03 '23 at 10:41

score 2 · Answer 1 · answered Feb 03 '23 at 10:44

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

Thanks for the heads up. "test result" - kinda hard to do that on a Windows XP box with VC6, because I think we ain't got no such boxes nomore :-) — Martin Ba, Feb 03 '23 at 16:11
@MartinBa - no any different here - xp or win11. can test this on any comp — RbMm, Feb 03 '23 at 16:18

score -1 · Accepted Answer · answered Feb 03 '23 at 16:22

// 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.

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

2 Answers2