Vomit

@trancexx That's interesting to hear: so you say I can simply NOT install a COM error handler, and not having the script bomb out? And just check @error? I'll try that tomorrow, thanks for the tip! Still leaves the clearing of @error to 0, I think, because I distinctly tested if it got reset by a COM call and it didn't.

@water: Yes, that's what I also concluded, but that leaves the 2 questions open. I tried playing with SetError inside my own error handler and it didn't make a difference, I always saw the COM error propagate back to the user script (which is nice BTW). The problem of presetting it to zero before the call, as you say, remains. So that's why I asked: Knowing what happens with the @error and the regular return value within a user error handler would be nice, because I think it is not well specified in the documentation.And having some level of abstraction (possibly not using @error) to make COM calls and have one single check after the call (without having to prepare for the call) would also be nice.For the moment I made something like ; Returns true if the last COM call returned COM_S_OK ; Must be called once after each COM call, to prepare for handling ; the next call Func COMSuccess() Local $success = $__COMError[0] = $COM_S_OK ; Consume the error and prepare for next COM call $__COMError[0] = $COM_S_OK Return $success EndFunc but I don't like the mandatory aspect of HAVING to call the COMSuccess() to make sure the next COM call is prepared, it's easy to forget if you don't see the COM call clearly (e.g. a property access) or don't care about the error. From a software architecture point of view it should be ideal to have some transparent layer handling this. But I don't see how it could be wedged in, as you say: there's no user-definable hook into a COM outgoing call.

Hello, I'm trying to have a more transparent behaviour when trapping COM errors. This means that I want a call to a COM object to map through to something I can easily check, preferably the @error variable. The example in ObjEvent uses "$g_eventerror = 1" to pass the error back to the script. But that is not so transparent because it needs to be reset every time before performing a potentially error-generating COM call. I also see a lot of SetError(1) at the end of COM scripts, but when I print @error after the COM call, it seems to be set to the COM error, no matter what is written in the error handler. This behaviour would actually be exactly what I need, except that the @error doesn't get reset by the COM call itself, so e.g. $oShell = ObjCreate("shell.application") _DebugReport(@error & " " & @extended) $oshell.open("D:") _DebugReport(@error & " " & @extended) $oshell.open ; missing parameter! _DebugReport(@error & " " & @extended) $oshell.open("c:") _DebugReport(@error & " " & @extended)will set the @error at the open call without parameters, but @error remains set from there on, even after the next successful call. So it would be necessary to reset it manually again just like $g_eventerror. In some scripts I see attempts to return 0 from the error handler as well. So my questions are: Is there a specification about if and what the error handler should return and SetError()?Is there a best practice of how to pass caught COM errors into the script for handling, that is as transparent and natural as possible (no preparation, preferably just mapped into @error)?Thanks in advance!