Comments on .NET tips, tricks and patterns: Making IDisposable more usable, part 1

Concerning Haskell: well, there are lots of practi...

2010-04-17T00:03:29.450+06:00

Concerning Haskell: well, there are lots of practically good ideas:
- LINQ came from it (monads)
- Parallelism is absolutely free in pure functional languages.
- It syntax is also very nice: short & clean.

So in fact, C# and F# took a lot from functional languages. But agree, currently usage of imperative style seems inevitable (= practically efficient).

Errrmm... "hence" is not exact word. it's evoked b...

2010-04-16T21:14:18.522+06:00

Errrmm... "hence" is not exact word.
it's evoked by agressive functional programming funs, epic vsl followers.

>>Nearly the same approach is used in Parallel Ext...

2010-04-16T20:35:18.272+06:00

>>Nearly the same approach is used in Parallel Extensions \ PLINQ - it also may throw AggregatedException in case of multiple concurrent errors. So I suspect that's the best option we had.

I suppose it's the only considerable option PLINQ have.

Aggregated exceptions causes separating catches.
I think exception handling is something like tolerance level definition. Also exception handling by design can be used to fight unsuitable API of 3rd party products.

Btw, Thx God I know imperative programming, hence I don't like Haskell.

Nearly the same approach is used in Parallel Exten...

2010-04-14T23:39:51.113+06:00

Nearly the same approach is used in Parallel Extensions \ PLINQ - it also may throw AggregatedException in case of multiple concurrent errors. So I suspect that's the best option we had.

Btw, exception handling in general is really a bit ugly way. Check out how this is implemented in pure functional languages like Haskell.

Interesting stuff, thx. About aggregated exceptio...

2010-04-14T12:49:48.775+06:00

Interesting stuff, thx.

About aggregated exception. Exception handling just cannot be done right. Otherwise it's not exception handling, it's control flow management. I'ts better to avoid exception features under this angle of view. I suppose something is wrong with exception aggregation...

"using" statement is limited to the same block of ...

2010-02-18T18:18:47.721+05:00

"using" statement is limited to the same block of code. But in real life you frequently create IDisposable objects in constructors and dispose them in your own IDisposable.Dispose - so these patterns are designed mainly for this case.

maybe it's a stupid suggestion but why don't you u...

2009-08-31T18:36:12.290+06:00

maybe it's a stupid suggestion but why don't you use the 'using ***' pattern?

if you use a resource with
using (var x = XXX)
{
}

you don't have problem about null checks, also about using more objects i think that the 'using' is more clear that your solution

using (var x1 = new x1())
using (var x2 = new x2())
{

}
i don't remember but maybe works also

using (var x1 = new x1(),
var x2 = new x2())
{
}