By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,671 Members | 1,387 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,671 IT Pros & Developers. It's quick & easy.

[Proposal] using statement enhancements

P: n/a
Mostly always you use the using clause you deal with native ressources, so
exception handlinjg is sooner or later inevitable.

so why do we need to write

try
{
using (File f = File.CreateText("bla.txt"))
{
}
}catch (IOExcepion e)
{
}

why don't we allow catch blocks directly attached to the using clause:

using (File f = File.CreateText("bla.txt"))
{
}
catch (IOExcepion e)
{
}

It is much shorter and readable. One of the problems with Exceptions is that
is often produces very deep nested code and at the end you do not know which
belongs to what.

The second idea I have is that we need some support for transactions in
code. Currently we have to write huge statements like that to enable safe
transaction handling:

try
{
BeginTransaction();
// stuff
Commit();
}
catch (SpecialException e)
{
Rollback();
throw new SpecialException ("Something fouled up here", e);
}
catch (Exception)
{
Rollback();
throw;
}

So I'd love to see that in future using would accept next to IDisposible a
new interface ITransaction:

interface ITransaction
{
void BeginTransaction();
void Commit();
void Rollback();
}

so we could write code like that:

using (dbconnection.Transaction)
{
// do stuff here
}

the property Transaction would return an (not necessarily a new) object
implementing ITransaction and BeginTransaction, Commit and Rollback are
automatically called. If the object additionally implements IDisposible
dispose is also called in the finally clause.

What do you think?
Nov 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
The second idea I have is that we need some support for transactions in
code. Currently we have to write huge statements like that to enable safe
transaction handling:


The usual idiom is something like:

Transaction t = Transcations.Begin(...);
bool committed = false;
try {
while ( still_not_done() )
t.Operate(...);
committed = t.Commit();
} finally {
if ( !committed )
t.Rollback();
}

Which nicely lets exception go to the caller of something goes wrong,
and completes cleanly otherwise.

--
Helge
Nov 16 '05 #2

P: n/a
Helge Jensen <he**********@slog.dk> wrote:
The second idea I have is that we need some support for transactions in
code. Currently we have to write huge statements like that to enable safe
transaction handling:


The usual idiom is something like:

Transaction t = Transcations.Begin(...);
bool committed = false;
try {
while ( still_not_done() )
t.Operate(...);
committed = t.Commit();
} finally {
if ( !committed )
t.Rollback();
}

Which nicely lets exception go to the caller of something goes wrong,
and completes cleanly otherwise.


Actually, the using statement covers this already:

using (Transaction t = Transactions.Begin(...))
{
.. do stuff ..
t.Commit();
}

Every transaction class I've seen implements IDisposable in a way such
that if it's disposed without committing, the transaction is rolled
back, and if it's disposed after committing that's a no-op.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #3

P: n/a
cody <de********@gmx.de> wrote:
Mostly always you use the using clause you deal with native ressources, so
exception handlinjg is sooner or later inevitable.
Well, I don't agree that exception handling is in any way inevitable
*in the same scope as the using statement*, but I agree it happens.
so why do we need to write

try
{
using (File f = File.CreateText("bla.txt"))
{
}
}catch (IOExcepion e)
{
}

why don't we allow catch blocks directly attached to the using clause:

using (File f = File.CreateText("bla.txt"))
{
}
catch (IOExcepion e)
{
}


Yup, that would be nice for the cases where you *do* need to handle
exceptions at the same level.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #4

P: n/a
For your first suggestion:
why don't we allow catch blocks directly attached to the using clause:

using (File f = File.CreateText("bla.txt"))
{
}
catch (IOExcepion e)
{
}


You have a problem when it comes to providing a useful error message in the
event of a syntax error. This is an important issue with the IDE as well.
For example, let's assume this syntax exists. Also, let's assume that
try-catch also continues to exist. The following errant code is entered in
the IDE. Where should the error be flagged? (At point one or point two?)

public void mycall()
{
try
{ // do some stuff
//point one
using (File f = File.CreateText("bla.txt"))
{
} // point two
catch (IOExcepion e)
{
}
} // point three

I didn't put in indentation on purpose... the compiler ignores indentation.

OK... so where's the bug? If an close brace is added at point one, then the
catch goes with the using. If the close brace is added at point two, then
the catch goes with the try. Assume there is a LOT of code in here. The
IDE could easily instruct the developer to add a brace at the wrong place.
In fact, it would be difficult to catch the error before point three (end of
the method)!

This is one reason why block groups (like "catch" and "else") are not reused
in multiple structures.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Nov 16 '05 #5

P: n/a
> You have a problem when it comes to providing a useful error message in
the event of a syntax error.


You must be joking if that is the only problem you have with that :)
In my experience, a missing } often lets the compiler point to the end of
the file or the beginning of the next class, even if the brace is missing
somewhere in the middle of the class. I have no problem with that because it
happens very rarely and usually its no problem to spot the error.
Nov 16 '05 #6

P: n/a
I'm really glad that you are not designing a language that I would have to
actually use, Cody.

I've been writing code professionally since the early 80's. The list of
languages is long, and the list of tools to write them in is longer.

I can tell you one thing: making a language less usable because you think
your structure is cool... will get you a dead language.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"cody" <de********@gmx.de> wrote in message
news:OO*************@TK2MSFTNGP10.phx.gbl...
You have a problem when it comes to providing a useful error message in
the event of a syntax error.


You must be joking if that is the only problem you have with that :)
In my experience, a missing } often lets the compiler point to the end of
the file or the beginning of the next class, even if the brace is missing
somewhere in the middle of the class. I have no problem with that because
it happens very rarely and usually its no problem to spot the error.

Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.