Ahh but we found this in production code (or code destined for production in
the near future.
This is the real scenario:
We have a TimedLock class that internally calls TryEnter on a monitor -
basically to allow is not to perform an infinite wait like the lock keywork
does. We wanted it scode based and so implemented the release of the lock in
IDisposable.Dispose so we had usage as follows
using( TimedLock.Lock(obj) )
{
// some stuff that needs thread safe access via obj
}
However, in one scenario, simply being able to acquire the lock meant that
the resource we were locking was ready for use therefore we simply needed to
immediately release the lock and use the resource in a readonly fashion.
So we had code like this
if( myhashtable.ContainsKey(s) )
{
using( TimeLock.Lock(s) )
{
}
}
else
{
// need to create the s entry in the hashtable and populate it
}
return myhashtable[s];
so you see its not lunatic coding that led us to discover this
Regards
Richard Blewett
DevelopMentor
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
Sent: 28 August 2003 17:52
To: [EMAIL PROTECTED]
Subject: [inbox] Re: [ADVANCED-DOTNET] Nasty bug in 1.0 and 1.1 compiler
Ouch. That's actually more serious than the original -- I would not have
imagined anyone needing (or thinking) to write a "using" statement with an
empty body. When would that be necessary (or even useful)?
In this code, do you need both the TRY and FINALLY blocks to be empty to see
the bug? That's also not a likely real-world construct, is it?
At 06:18 AM 8/28/2003 -0400, Richard Blewett wrote
>On Thu, 28 Aug 2003 03:53:19 -0400, Vijay M <[EMAIL PROTECTED]> wrote:
>
>>>commenting out the using block in the if block or putting code after the
>>>using block in the if resolves the problem
>>
>>Richard, i am not quite able to understand the solution for this bug. It
>>would be really helpful for many of us if you can explain it in more
detail
>>on why such a confusion in the compiler happens in the first place and why
>>the using block is responsible for creating this behaviour.
>>
>
>Vijay, unfortunately I am not privy to the C# compiler code and so have no
>idea why it is unable to deal with this situation.
>
>I don't think its the using block per se as I have translated it into the
>try/finally block that using resolves to and the error still remains. Here
>is the absolute bare bones to repro the problem
>
><code>
>class App
>{
> static void Main(string[] args)
> {
> if( args.Length == 0 )
> {
> Console.WriteLine("in if");
> try
> {
> }
> finally
> {
> }
> }
> else
> {
> Console.WriteLine("in else");
> }
> }
>}
></code>
>
>Regards
>
>Richard Blewett
>DevelopMentor
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor® http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
===================================
This list is hosted by DevelopMentor® http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
