Weblogs Forum - What Are Your C# Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your C# Pain Points, Really?

29 replies on 2 pages. Most recent reply: Dec 25, 2007 10:22 PM by Peter Kellner

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]

Matt Vogt

Posts: 1
Nickname: mattv
Registered: Mar, 2007

Re: What Are Your C# Pain Points, Really?

Posted: Mar 6, 2007 5:33 PM

As a C++ developer interloping with C#, I have only two complaints that come to mind immediately:

1. Lack of type deduction for generic classes/functions
2. Woefully inadequate 'where' clauses, which could have provided a useful general constraints mechanism, but don't.

Carsten Saager

Posts: 17
Nickname: csar
Registered: Apr, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 13, 2007 2:23 AM

As I find C# in general more powerful and elegant than Java:

* .NET
C# without .NET is nothing and .NET support community-wise - in comparision with Java-API, forget it.

.NET stuff ties you to the Windows platforms, sometimes in very subtle ways, so Mono is not a true gateway to other platforms

* All-Purpose Paradigm
I think the time of all-purpose programing languages are over. Without giving in to the performance needs(?) of some the language would have been much cleaner and safer to use in large scale projects without unmanaged objects and unsafe calls.

*Partial-classes
Brillant idea, but with the same problem as known from C/C++ days (includes). Not even VS2005 does handle them well.

*Multiple compile targets
This multiplies the development costs; I was so happy that we got rid of all this artistry with parallel builds

The funny thing is that C# as very few pain points in compraison to Java, but when you are a middle-sized organization, working strongly cross platform and not yet settled into your final architecture/process; those become blocking points.

Jan Persson

Posts: 3
Nickname: janpersson
Registered: Nov, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 14, 2007 7:38 AM

Not having the possibility to declare a variable as constant inside a method is probably what I miss the most from Java.

Sure you have const, but it does not work on instances and readonly can only be used on member variables. Maybe I'm just missing out on something, but until someone enlights me, I find this annoying.

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really?

Posted: Mar 14, 2007 9:15 AM

the const/readonly pairing is odd. readonly seems like a hack to me.

Amr Ali

Posts: 3
Nickname: amreg
Registered: Aug, 2005

Re: What Are Your C# Pain Points, Really?

Posted: Mar 19, 2007 3:56 PM

Yes, C# has really benefit from java, How ever, i do miss this features in C#:

1- Checked exceptions: really a big bitfall of C# is not to have a checked exceptions.

2- Enum as classes: enum in C# are just "enums".
3- Final: C# const is a real mess.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 20, 2007 9:47 AM

> Yes, C# has really benefit from java, How ever, i do miss
> this features in C#:
>
> 1- Checked exceptions: really a big bitfall of C# is not
> to have a checked exceptions.

This was no accident. Many Java programmers have concluded that checked exceptions has turned out to be a bad idea and it's hard to find any non-Java programmers that think it was a good idea. Now that Sun is letting go of control of Java, we may see this become an optional feature someday.

>
> 2- Enum as classes: enum in C# are just "enums".

In the old days Sun's line on enums was that they were unecessary. Then when C# added them, Sun decided that not only were they necessary but that they needed to have behavior.

The real value of enums is to group together a set of related named constants. If an enum can be type-safe as well (as they are in C#) that's icing on the cake. They don't really need to be classes.

> 3- Final: C# const is a real mess.

I don't see the problem with const being static. Why would each object need its own version of a constant?

Jan Persson

Posts: 3
Nickname: janpersson
Registered: Nov, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 21, 2007 2:34 PM

>> 1- Checked exceptions: really a big bitfall of C# is not
>> to have a checked exceptions.
>
> This was no accident. Many Java programmers have concluded
> that checked exceptions has turned out to be a bad idea and
> it's hard to find any non-Java programmers that think it was
> a good idea. Now that Sun is letting go of control of Java,
> we may see this become an optional feature someday.

Well, I also used to think that checked exceptions in Java were an overkill, but I have changed my mind after working with C# for some time.

You are always feeling a bit uneasy when you are using a library in C#, since you really never know what kind of exceptions a specific method may throw. In Java this is always clear and they must always be handled.

I think managed exceptions gives us to better code, even if they can be annoying at times.

>> 3- Final: C# const is a real mess.
> I don't see the problem with const being static. Why would > each object need its own version of a constant?

Why not? Isn't it a very common usage scenario that you are having a member variable that should be kept constant after it has been initialized.

The final keyword in Java tells the compiler that after the initialization of a variable has taken place, you are not allowed to touch it (and the initialization can be arbitrary complex since it also has blank finals) and I personally find this behaviour much better than way C# is handling constants.

But apart from these two minor things, I think C# is a much better language.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 21, 2007 4:51 PM

> You are always feeling a bit uneasy when you are using a
> library in C#, since you really never know what kind of
> exceptions a specific method may throw. In Java this is
> always clear and they must always be handled.

You know if you check the documentation. In most cases handling the exception other than at the top level is the wrong thing to do, so most of the time in Java you're just decorating your code with compiler-enforced redundant exception documentation.

Of course if somewhere deep in a call chain an exception is added, all the code that uses that chain has to be modified even if it's not intended to handle exceptions.

>
> >> 3- Final: C# const is a real mess.
> > I don't see the problem with const being static. Why
> would > each object need its own version of a constant?
>
> Why not? Isn't it a very common usage scenario that you
> are having a member variable that should be kept constant
> after it has been initialized.
>

C# const symbols are static. They are intended for compile-time constants. It's readonly fields that have the behavior you're looking for - they can only be modified in a constructor. So C# allows true constants to be highly efficient while readonly offers the flexibility of run-time init. Sounds like the best of both worlds to me.

Jan Persson

Posts: 3
Nickname: janpersson
Registered: Nov, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 22, 2007 12:36 PM

> > You are always feeling a bit uneasy when you are using
> a
> > library in C#, since you really never know what kind of
> > exceptions a specific method may throw. In Java this is
> > always clear and they must always be handled.
>
> You know if you check the documentation.

Sure, but that can only be done if it the exceptions are indeed documented, which is not always the case with some of third party libraries I have encountered.

> In most cases handling the exception other than at the
> top level is the wrong thing to do, so most of the time
> in Java you're just decorating your code with
> compiler-enforced redundant exception documentation.

The exceptions you have to handle are exactly the ones the writer of a method choose to expose. If he exposes more than "top-level-exceptions", I would say that the library has a design flaw. If that is the case it would be obvious when you look at the method signature in Java, but more of a guessing game in C#.

> Of course if somewhere deep in a call chain an exception
> is added, all the code that uses that chain has to be
> modified even if it's not intended to handle exceptions.
>
> >
> > >> 3- Final: C# const is a real mess.
> > > I don't see the problem with const being static. Why
> > would > each object need its own version of a constant?
> >
> > Why not? Isn't it a very common usage scenario that you
> > are having a member variable that should be kept
> constant
> > after it has been initialized.
> >
>
> C# const symbols are static. They are intended for
> compile-time constants. It's readonly fields that have the
> behavior you're looking for - they can only be modified in
> a constructor. So C# allows true constants to be highly
> efficient while readonly offers the flexibility of
> run-time init. Sounds like the best of both worlds to me.

Still, as I said in my original post, you cannot mark variables on the stack as readonly, which is possible with final in Java. This is something I really miss in C#.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 22, 2007 2:56 PM

> > You know if you check the documentation.
>
> Sure, but that can only be done if it the exceptions are
> indeed documented, which is not always the case with some
> of third party libraries I have encountered.

Poor work on documentation, design, or implementation of a library can't be solved by checked exceptions. Even if it's a Java library, the implementation might just be silently swallowing the exceptions anyway.

> The exceptions you have to handle are exactly the ones the
> writer of a method choose to expose. If he exposes more
> than "top-level-exceptions", I would say that the library
> has a design flaw. If that is the case it would be obvious
> when you look at the method signature in Java, but more of
> a guessing game in C#.

One would hope that the exceptions that are exposed are the ones that aren't appropriate to be handled in the method itself.

The point is that if method D which can throw exception 1 is called by method C which can also throw exception 2 is called by method B which can throw exception 3 is finally called by method A and it isn't appropriate for any of these exceptions to be handled by B, C or D methods, method A has to handle them or declare them throwable. Now if method D is modified to throw another exception, methods A,B and C will no longer compile. In a large system this could be a maintenance nightmare.

> Still, as I said in my original post, you cannot mark
> variables on the stack as readonly, which is possible with
> final in Java. This is something I really miss in C#.

Perhaps I don't fully understand what you're trying to accomplish. It's true that C# doesn't allow you to declare a local variable as readonly, but you can declare it as const. What can you do with final in this case, that you can't do with const? Perhaps a simple example would make it clear.

Eric-Alexander Schaefer

Posts: 2
Nickname: eas
Registered: Sep, 2005

Re: What Are Your C# Pain Points, Really?

Posted: Mar 23, 2007 5:20 AM

I think Jan is talking about:


int doSomething(final Thing t) {
    // do something with t but do not change it
}

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really?

Posted: Mar 23, 2007 10:19 AM

> I think Jan is talking about:
>


> int doSomething(final Thing t) {
>     // do something with t but do not change it
> }
>

Well, if Thing is a value type or string, it couldn't be written to in C# because parameters are passed by value. If Thing is a non-string reference type, how much value does final really provide? Look at this:


int doSomething(final Thing t) {
    // do something with t but do not change it}
    t = new Thing(); // This low-probability mistake won't compile
    t.clearIrreplaceableData(); // final doesn't protect state
    iEatFinalForLunch(t); // This will compile without error    
    return 0;
}
    
void iEatFinalForLunch(Thing t)
{
    t = new Thing();
}

Final in this context gives a false sense of security. Doing it right would protect object state and would require a run-time check and a new exception. I think the designers of C# didn't want to take
the performance hit to do it right and didn't want to provide a partial solution as Java does.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Part of my example was bogus

Posted: Mar 23, 2007 12:00 PM


> int doSomething(final Thing t) {
>     // do something with t but do not change it}
> t = new Thing(); // This low-probability mistake won't
> on't compile
> t.clearIrreplaceableData(); // final doesn't protect
> tect state
> iEatFinalForLunch(t); // This will compile without
> hout error    
>     return 0;
> }
>     
> void iEatFinalForLunch(Thing t)
> {
>     t = new Thing();
> }
> 
>

With or without final and its associated compile error, nothing in these methods are going to change which Thing object the caller's value of t is pointing to.

So obviously I don't understand the purpose of final as applied to a method parameter.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Part of my example was bogus

Posted: Mar 23, 2007 2:11 PM

> So obviously I don't understand the purpose of final as
> applied to a method parameter.

Yeesh, some people can't understand anything. Don't you know it makes you feel better to put final there? It feels more solid and well, more final.

It's like this kind of code:

public void foo( SomeObject obj )
{
   obj.doNiftyStuff();
   someOtherMethod( obj );
   // ...Lots of other important stuff and byzantine logic...
 
   return;
}

Because, you know, without that explicit return, the method might never return.

Peter Kellner

Posts: 10
Nickname: pkellner
Registered: Feb, 2002

Re: What Are Your C# Pain Points, Really?

Posted: Dec 25, 2007 10:22 PM

Not having the choice for different implementations of functionality. don't like how WCP (windows communication foundation) works? Oh well, sorry. (for example)

Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic