Sorry for the very late reply.
> I'm not sure this is true for StackOverflowException. I think the CLR
team
> is working on hardening the finalizer to stack-overflow exceptions... at
> least the ones that occur in managed code; it may always be prone to death
> and destruction via unmanaged stack
[Was out of town a few days. Hope this isn't too stale. Comments interleaved.]
At 11:02 AM 4/8/2004, John Elliot wrote (in part)
>>The sample code shows one of the gazillion ways it's possible to cause an
>>object to be in an "illegal" (a.k.a. undefined or unexpected) state [snip]
>
>What state
>I think perhaps we (developers) have become far too forgiving of apps
>that crash. :-) Frankly I am very annoyed when an app that I've paid
>good money for crashes and takes my data with it or causes me to lose
>time. For this reason, it seems to me that applications should try
very
>hard to rec
>The sample code shows one of the gazillion ways it's possible to cause
an
>object to be in an "illegal" (a.k.a. undefined or unexpected) state --
a
>state that violates one or more "class invariants" (even if not
formally
>defined). Being exception-ignorant (whether inside the constructor or
>els
>> It's true that a
>> reference to the new instance is not returned, but the instance is
>> always 'created' (I'm not sure what the definition of 'construction'
is
>> in this case, but certainly an object id is allocated, etc.). This is
>> obviously the case, since you have access to the 'this' po
>Can't something like this VB.NET code guarantee that there is no
>exception raised in a Finally block:
Kinda... but you don't want to silently swallow those exceptions, though.
You might be masking a serious problem -- and you'd never know about it!
The argument we're beating around is this: wou
Rick Byers wrote:
Of course the solution
is to prevent throwing exceptions from my finally blocks, but this can be
very hard to guarantee, and you generally won't discover a problem until
you've lost information about a more important bug that needs to be tracked
down.
Can't something like this VB
The sample code shows one of the gazillion ways it's possible to cause an object to be
in an "illegal" (a.k.a. undefined or unexpected) state -- a state that violates one or
more "class invariants" (even if not formally defined). Being exception-ignorant
(whether inside the constructor or elsew
> Someone commented that 'the object is not constructed' if an exception
> is thrown from the constructor, but that's not true.
This is true in C++ (unmanaged) - when a constructor throws an exception
(while new is being performed), then just-allocated memory must be freed by
the runtime. Since a
> On Sun, 4 Apr 2004 22:53:36 +1000, John Elliot <[EMAIL PROTECTED]> wrote:>
>difficult to handle. I design my code such that exceptions don't
happen.
>If they do, then I have a bug and I need to fix it, I don't pretend
that
>I can really 'handle' an exception (obviously there are cases where you
>
Wow, great point, John!
-S
On Sun, 4 Apr 2004 22:53:36 +1000, John Elliot <[EMAIL PROTECTED]> wrote:
>>> Since you can't propagate two exceptions
>>> at the same time,
>>
>>Ironically .NET does offer us a way to propagate multiple exceptions --
>the
>>InnerException property gives each exception
>> Since you can't propagate two exceptions
>> at the same time,
>
>Ironically .NET does offer us a way to propagate multiple exceptions --
the
>InnerException property gives each exception the potential,
effectively, to
>represent a linked-list of exceptions (composite design pattern).
>
>I agree
Interesting point Rick, I haven't heard anybody bring this issue up
before. This is turning into a great thread, in general.
Two questions/comments:
> (i.e. it does not terminate the finalizer
> thread, future finalizations still happen).
I'm not sure this is true for StackOverflowException. I
I agree that exceptions from C++ constructors can be dangerous, although you
can dealing with them safely if you're careful. Yes this is fine in .NET.
However, exceptions from C++ destructors are always dangerous, and this is
still true in .NET.
In C++, if an exception can escape a destructor, it
yes I didn't take care of that.sorry
Muhammad Adel
"The secret to creativity is knowing how to hide your sources". Einstein
- Original Message -
From: "Chad M. Gross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 02, 2004
Muhammad, you didn't read my note close enough. The _myIntPointer is a
private field member of Class1 so you obviously do not have access to it
as you are showing below. Take another look at my original note.
Chad
>you can use _finally (C++) or finally (C#) blocks to make sure that no
>memory l
In response to the questions direct at me for being a thicket:
Ok, having thought about it a bit more and read the thinking on the list, my
hangovers from C++ c'tor exception throwing have been alleviated.
You live and learn :)
adam
===
This list is hosted by Dev
Throwing exceptions from instance constructors poses no problem. However,
throwing them from *static* constructors is not a good idea, since, the
static constructors, as opposed to instance constructors, aren't called
explicitly, so there's no nice mechanism to handle them.
HTH,
Stefan
I agree,
rom: "Chad M. Gross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 31, 2004 11:23 PM
Subject: Re: [ADVANCED-DOTNET] Exceptions in Constructors
Chris,
Your brain was hammered appropriately. Say in C++ you had a class called
Class1 that had a private fiel
Huh? Isn't that the idea, Adam -- that 'a' remains null? It would be awful
if 'a' came away from that in some not-null, ambiguous,
partially-constructed state. Right? (That was the problem with C++, which
the original poster alluded to.)
At the IL level, the instantiation of A (newobj) and the
Hi,
Adam wrote:
AS> Its still got bad idea stamped all over it. The object would
AS> not get constructed, this is almost certainly doc'd somewhere.
Mmm ... I'm not sure if I'd label that a disadvantage. When, I ask for the
construction of an object and something goes wrong, I find it reason
27;s by design.
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Straughan
Sent: Thursday, April 01, 2004 2:50 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Exceptions in Constructors
Its still got bad idea stamped
Chris,
Your brain was hammered appropriately. Say in C++ you had a class called
Class1 that had a private field member int* _myIntPointer. In your
constructor you intending on initializing the pointer to something using
the new operator and cleaning up after yourself in the destructor
using "if (
A little scenario in C++
class X(
X()
{ CString x = new CString("dsadsad");
throw exception.
}
}
This causes a memory leak, because CString x is never deleted.
.NET has a garbage collector, so this is not an issue in .NET!
According to me: feel free to use exceptions in constructors!
Eve
Exceptions in unmanaged C++ were totally broken, for several reasons...
They are far less broken, in .NET... yes, by all means, throw!
But don't go overboard with them. Throw statements are still rather
expensive, performance-wise.
Cheers,
-Shawn
http://www.windojitsu.com/
-Original Messa
Chris,
CS> In a nutshell, as a C++ developer, various people hammered
CS> into my brain that throwing an exception in a constructor
CS> (whether intentionally or by performing some action which
CS> would cause an exception to be thrown) was extremely bad.
CS> However, my research seems t
Its still got bad idea stamped all over it. The object would not get
constructed, this is almost certainly doc'd somewhere.
The following code outputs the string "null"
using System;
public class MyClass
{
public static void Main()
{
A a = null;
try
{
27 matches
Mail list logo
