Unmanaged exception caught how in managed code?

[Bret Pehrson]

Suppose the following:

// Unmanaged code
class UnmanagedException /* not visible outside of unmanaged code */
{
};
void DoSomething() /* visible (exported) to managed code */
{
throw new UnmangedException();
}

// Managed code
// Call into unmanaged code
try
{
DoSomething();
}
catch (???)
{
}
What is/are suitable types to catch in the managed code?

I see SEHException and its parent ExternalException, but these (automatic)
wrappers seem to be based on COM hresult types of exceptions.

My understanding is that the managed framework automatically catches,
repackages, and rethrows the unmanaged exception, but as what?

Thanks

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Yan-Hong Huang[MSFT]]

Hello Bret,

Thanks for posting in the group.

Based on the description, the question is: How to trap a unmanged type
exception in managed code? Please feel free to post here if I misunderstood
the question.

In fact, we can catch the common language runtime exception
(System::Exception) and the unmanaged exception (C++ struct) in Managed
Extensions for C++ code. Please refer to the following sample code:

#using <mscorlib.dll>
using namespace System;

struct S {
};

void foo(int i) {
if (i == 0) {
throw (new S());
}
else {
Exception *e = new Exception;
throw e;
}
}

int main() {
int nRes = 1;
for (int i = 0; i < 2; i++) {
try {
foo(i);
}
catch (S* s) {
(s);
Console::WriteLine(S"Caught an unmanaged exception!");
nRes -= 2*i;
}
catch (Exception* e) {
Console::WriteLine(S"Caught a managed exception: {0}", e->ToString());
nRes -= i;
}
}

return nRes;
}

Note that the same try block is guarded by both of the catch statements
that catch managed and unmanaged exceptions individually. Also note that
the code generated by this sample is completely managed code.

You can also refer to
http://msdn.microsoft.com/library/en...edsampledemons
tratesthrowingcatchingmanagedunmanagedexceptionswi thinsingleprocess.asp?fram
e=true for the details on this sample.

Does that answer your question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Stoitcho Goutsev \(100\) [C# MVP]]

Hi Bret,
You can catch unmanaged exception in c# but you can't use them. you can only
rethrow them

if you have try/catch block like this
try
{
....
}
catch
{
...
throw;
}

the catch block will catch all exceptions (managed and unmanaged) and the
*thow* operator will rethrow catched exception *AS IS*.

This is the only way you can catch unmanaged exception with try/catch block
in c# and your choices are either to swallow it or rethrow it.

--
B\rgds
100
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...

Suppose the following:

// Unmanaged code
class UnmanagedException /* not visible outside of unmanaged code */
{
};
void DoSomething() /* visible (exported) to managed code */
{
throw new UnmangedException();
}

// Managed code
// Call into unmanaged code
try
{
DoSomething();
}
catch (???)
{
}
What is/are suitable types to catch in the managed code?

I see SEHException and its parent ExternalException, but these (automatic)
wrappers seem to be based on COM hresult types of exceptions.

My understanding is that the managed framework automatically catches,
repackages, and rethrows the unmanaged exception, but as what?

Thanks

--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

[Arnold the Aardvark]

I know this is really a nit-picky question, but I'm still getting
to grips with MC++'s rules and regs:

//> throw (new S());
throw S(); // Do we need to allocate from the freestore?

//> catch (S* s) {
catch (S& s) // Isn't it preferable to catch by reference?

//> (s); // What does this do?

You mention that all the resulting code is managed. Is the 'new S()'
required to make this the case?

Thanks.
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Yan-Hong Huang[MSFT]]

Hello,

For your quesitons,

1) and 2):
throw S() --> catch (S& s)
throw ( new S()) --> catch ( S* s)
3) If you add a constructor to struct S, you can see that (s) will call its
constructor.
For an example,
struct S {
S(){Console::WriteLine ("enter structure S");}
};

4) new S() is not related to managed or unmanged.

Thanks.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Arnold the Aardvark]

> 3) If you add a constructor to struct S, you can see that (s) will call

its constructor.
But the object is already fully constructed in the throw statement.
Am I being obtuse? I've never C++ like this before.
4) new S() is not related to managed or unmanged.

Thanks. That's what I wanted to know.
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Hendrik Schober]

Yan-Hong Huang[MSFT] <yh*****@online.microsoft.com> wrote:

[...]
4) new S() is not related to managed or unmanged.
I wouldn't know about MC++, but in
std C++ 'throw new S()' certainly
seems a very bad idea.
Thanks.

Best regards,
Yanhong Huang

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Yan-Hong Huang[MSFT]]

Hi Schobi,

You are correct. This is just extracted from some sample code. throw S()
--> catch (S& s) is better.

While the Standard doesn't specify where the exception object in catch (xc
& x) is stored, most implementation maintain a special exception stack, on
which exception are constructed (however, the Standard does not allow the
implementation to use free store memory for that purpose). Passing an
exception by reference is preferred to passing an exception by value for
several reasons: as you suggested, it short circuits the process of passing
the exception object to its handler (only a reference is copied rather than
a full-blown object). However, pass by reference also ensures that derived
exceptions are not sliced. Finally, it enables you to modify the exception
and then pass it on to another handler (i.e., a re-throw) with the changes
made to that object.

Thanks for pointing it out. :)

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Yan-Hong Huang[MSFT]]

Hi Arnold,

Sorry for my mistake. (s) has no effects here. By using ildasm.exe, you can
see that this sentence is ignored by compiler and have no effect.

It just likes:
struct S a;
(a);

It can pass building.

BTW, if you want the struct is managed code, you need to define it as: __gc
struct...

Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hendrik Schober]

Mhmm. While catching by reference certainly
is better than catching by value (beeing
who I am I mostly catch by const reference),
actually I was refereing to your
throw new S()
as this begs the question of who will be
responsible for deleting the object.

Schobi
Yan-Hong Huang[MSFT] <yh*****@online.microsoft.com> wrote:

Hi Schobi,

You are correct. This is just extracted from some sample code. throw S()
--> catch (S& s) is better.

While the Standard doesn't specify where the exception object in catch (xc
& x) is stored, most implementation maintain a special exception stack, on
which exception are constructed (however, the Standard does not allow the
implementation to use free store memory for that purpose). Passing an
exception by reference is preferred to passing an exception by value for
several reasons: as you suggested, it short circuits the process of passing
the exception object to its handler (only a reference is copied rather than
a full-blown object). However, pass by reference also ensures that derived
exceptions are not sliced. Finally, it enables you to modify the exception
and then pass it on to another handler (i.e., a re-throw) with the changes
made to that object.

Thanks for pointing it out. :)

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Yan-Hong Huang[MSFT]]

Hi Hendrik,

Yes, that is why I said "throw S() --> catch (S& s) is better." in my
former post in the first paragraph. :) In this way, we don't need to delete
S object later.

Have a good day.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hendrik Schober]

Yan-Hong Huang[MSFT] <yh*****@online.microsoft.com> wrote:

Hi Hendrik,

Yes, that is why I said [...]
I see. Sorry for the confusion.
Yanhong Huang

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Yan-Hong Huang[MSFT]]

:)

BTW, Bret, do you have any more concerns on this question?

Thanks and have a good day.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.