I don't know much about the InnerException implementation, but wouldn't it solve the
problem if A became the InnerException of B? Then you'd have the information (if you
know to dig for it).
After all, the call to Dispose was "caused by" (and is executing prematurely, possibly
breaking the con
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
Are you asking for a "business rules engine" or an infrastructure for "workflow
management"? I would have assumed the latter from your question, but skelta.com has
the former.
At 06:23 AM 4/1/2004, Bill Bassler wrote
>I'm trying to determine if there currently any open source workflow
>implemen
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 5:16 PM
Subject: Re: [ADVANCED-DOTNET] Exceptio
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,
My reasoning as to why it works with string and not DateTime is that string
is a reference type, while DateTime is a value type. If the string reference
is null, the serialization engine doesn't bother to serialize the structure
(attribute in this case). This contradicts your point with respect to
you can use _finally (C++) or finally (C#) blocks to make sure that no
memory leaks happen.see the
following code:
Class1* c = NULL;
try {
c = new Class1();
c.DoSomething();
}
catch {char* msg) {}
finally
{
if (c==Null)
{
if ( _myIntPointer!=NULL)
{
Have you tried to [XmlIgnore] the actual DateTime member, and serialize a
string rep instead? This is what a lot of us do anyway, in order to
control the formatting... I believe null string fields aren't serialized,
so it'd be good for that too.
http://www.windojitsu.com/blog/stillmoreonxmlseria
J.,
thanks for this information. It looks very much like the cause of the
problem.
I wonder why purely managed applications do not suffer from this issue
though.
Of course, I'm using .NET framework 1.1.
As I has already mentioned, my own googling finished with no success just
like yours.
Any fur
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
Sorry, I mis-spoke. We have a webmethod that takes as a parameter an enumeration type.
This is a normal .NET enumeration. Inside of its definition it defines the associated
integer values. None of this is actually done using XML.
To be completely honest, I don't think that what we want to do can
Throwing exceptions in a constructor is perfectly fine in .Net. And in many
circumstances, it is the Right Thing.
If a constructor cannot build a valid instance of a class, then it should
throw an exception -- just like any other method.
One key difference between virtual methods in .Net and in
16 matches
Mail list logo
