overload lock command? maybe others?

[not_a_commie]

I'd like to be able to overload the lock command so that I could log
an entry on lock and unlock. Any ideas on how to do this?

I think it would be powerful if you could inherit from a few keywords
in C# like this example:

static keyword MyLock : lock {
public MyLock(object obj) : base(obj) { log a message when entering
scope }
public ~MyLock() { log a message when going out of scope }
}

I could also see it being useful with the "using" keyword. I could see
it being very useful with try/catch/finally, but I think that would
conflict with the current method used for interrupting the code flow
(a painfully slow OS-level registration and interrupt).

[Barry Kelly]

not_a_commie wrote:

I'd like to be able to overload the lock command so that I could log
an entry on lock and unlock. Any ideas on how to do this?

Create an object that implements IDisposable, and use

using (MyLock.Lock(fo o))
{
}

.... instead.

E.g. roughly:

class MyLock : IDisposable
{
object _obj;

public MyLock(object obj)
{
_obj = obj;
if (_obj != null)
{
Monitor.Enter(_ obj);
// logging
}
}

public void Dispose()
{
if (_obj != null)
{
Monitor.Exit(_o bj);
// logging
}
_obj = null;
}
}

I could also see it being useful with the "using" keyword.

You can use the above idiom with 'using' too, by 'using' a proxy, and
passing the actual object to the constructor, and exposing it via a
property of the proxy.

I could see
it being very useful with try/catch/finally,

Another technique is to pass the code whose context you want to wrap as
an anonymous delegate. E.g.:

delegate void Proc();

static void MyWrapper(Proc proc)
{
try
{
proc();
}
catch (Exception ex)
{
// do something with ex, e.g. show a dialog
}
}

// ...

MyWrapper(deleg ate
{
// My code that might throw
});

but I think that would
conflict with the current method used for interrupting the code flow
(a painfully slow OS-level registration and interrupt).

-- Barry

--
http://barrkel.blogspot.com/

[Brian Gideon]

On Mar 15, 12:30 pm, Barry Kelly <barry.j.ke...@ gmail.comwrote:

Create an object that implements IDisposable, and use

using (MyLock.Lock(fo o))
{

}

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

[Barry Kelly]

Barry Kelly wrote:

using (MyLock.Lock(fo o))

class MyLock : IDisposable
{

Missing, is of course:

public static MyLock Lock(object obj)
{
return new MyLock(obj);
}

object _obj;

I've used this technique to get nice syntax for other primitives, such
as Mutex, ReaderWriterLoc k, etc.

-- Barry

--
http://barrkel.blogspot.com/

[not_a_commie]

Barry Kelly wrote:

using (MyLock.Lock(fo o)) ...

Thank you, Barry, very much. That was exactly what I needed to know. I
had not heard of the Monitor class, but that looks to be exactly what
I needed.

I can't see how this would apply to try/catch. It's too bad that the
try/catch stuff has to go all the way to the OS level to stop from
executing code. Here's the document MS responded with for my feedback
(id 256733) on the topic: http://www.microsoft.com/msj/0197/ex...exception.aspx

[Barry Kelly]

Brian Gideon wrote:

On Mar 15, 12:30 pm, Barry Kelly <barry.j.ke...@ gmail.comwrote:

Create an object that implements IDisposable, and use

using (MyLock.Lock(fo o))
{

}

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

I read somewhere that AndersH regretted adding 'lock' after adding
'using'.

-- Barry

--
http://barrkel.blogspot.com/

[Barry Kelly]

not_a_commie wrote:

Barry Kelly wrote:

using (MyLock.Lock(fo o)) ...

Thank you, Barry, very much. That was exactly what I needed to know. I
had not heard of the Monitor class, but that looks to be exactly what
I needed.

I can't see how this would apply to try/catch.

The second approach I listed, the delegate approach, can easily be
applied to try/catch. You pass the code as an anonymous delegate as an
argument.

It's too bad that the
try/catch stuff has to go all the way to the OS level to stop from
executing code.

I typically implement my event handlers inside anonymous delegates
passed to wrappers, as indicated in my grandparent post.

Alternatively, you can add a handler to either:

1) Application.Thr eadException - for exceptions thrown during Windows
message processing, typically due to e.g. throwing an exception in a
control's event handler.

2) AppDomain.Unhan dledException - for those exceptions that would
otherwise fall off the entire thread's stack.

-- Barry

--
http://barrkel.blogspot.com/

[Jon Skeet [C# MVP]]

Brian Gideon <br*********@ya hoo.comwrote:

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

Because they were copying Java ;)

Those following this thread may be interested in the locking classes
I've got in my utility library:

http://pobox.com/~skeet/csharp/miscu...e/locking.html

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[not_a_commie]

Why did they choose to create

the lock keyword anyway?

To understand that one must first understand why we need a lower-case
"string" keyword.