5

I have a whole sequence of interlinked questions. I would like to know answers for all of them independantly, so *yes*, some of them appear to be X-Y questions; but I do want to know the solution to them anyway!. See end of question for list of other questions in this set.

I have a situation in which calling Marshal.GetExceptionForHR(code, pointers) throws an AccessViolationException.

Apparently this a VeryBadThing. So bad that try...catch just shrugs at me and wanders off for a fag ... which I didn't know was a thing :(

Suppose a premise of "calling .GetExceptionForHR() is what I want to do" (see other questions for a discussion of whether this is a good idea!).

Suppose further that whatever causes the AccessViolation is unavoidable in some scenarios.

Given those premises, is there any way to predict in advance that calling them method will blow up? Some equivalent of TryGetExceptionForHR() that'll return false rather than blowing up my entire Program.

Other questions in this problem set.
Brondahl
  • 7,402
  • 5
  • 45
  • 74
  • Related: https://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception – Rich Feb 27 '20 at 10:20
  • The *pointers* argument must be an IErrorInfo COM interface pointer. The odds that you got a valid pointer are zero, this is not COM interop code. Passing a bad pointer is indeed quite likely to trigger an AVE. – Hans Passant Feb 27 '20 at 13:31
  • 3
    I disagree that this is a duplicate of https://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception. This question is asking "Can I predict in advance that if I call Marshal.GetExceptionForHR (under given circumstances). that it will throw an AccessViolationException, and if so, how can I predict this?" The question that it is marked as a duplicate of, on the other hand, is asking "how do I handle an AccessViolationException (that has already been thrown)?" These are clearly not duplicates of each other. – Some Guy May 16 '20 at 09:41
  • 1
    @SomeGuy I've had several comments agreeing with me (presumably kicked off by the discussion in meta.) I've therefore voted to reopen – Brondahl May 16 '20 at 11:05

1 Answers1

0

Just having a look at the Microsoft docs, Marshall.GetExceptionForHR doesn't throw an exception that can be caught.

Instead, they recommend using Marshall.ThrowExceptionForHR to get a thrown exception that you can then handle. This does not throw an exception when using a success HResult.

If you want to use Marshall.GetExceptionForHR then double-check that the correct pointer is being used. IntPtr(0) will use the current IErrorInfo interface while IntPtr(-1) will attempt to reconstruct the exception from just the code.

It's also possible that rather than throwing unexpected exceptions, GetExceptionForHR just returns the unexpected exception from a catch block e.g.:

catch(Exception ex)
{
   return ex;
};

Unfortunately, I can't be 100% certain at this point, I'm trying to track down the Marshall class on Microsoft's Github and I'll run some of my own attempts to see if I can get the same effect as yourself.

Related links:

Aaron
  • 167
  • 1
  • 10