Results tagged “C#”

Some time ago I stumbled over a neat trick in programming languages which understand C++-like comment lines (single- and multi-lined comments). This allows toggling between two different blocks of code by just adding or removing a simple '/' character in the first line.

    /*  <<- Add/remove one '/' here to toggle active code block
    String mode = "release";
    String mode = "debug";

I found this somewhere on but couldn't locate the article containing this again. I found a reference to this here but I guess this trick is much, much older than this article.


A recent blog entry posted in Argonauts blog deals with a C# codepiece which is valid at the first look and even compiles cleanly but failes gracefully with a runtime exception when executed.

Argo shows the C# code for his example but (as he also mentions) the same code can be used in a Java example. The following class hirarchy...

class BaseType {

class SubTypeA : BaseType {

class SubTypeA : BaseType {

looks innocent so far. But if it is used the following way

public static void main(String[] args) {
  BaseType[] baseArray = new SubTypeA[3];

  baseArray[0] = new BaseType();
  baseArray[1] = new SubTypeA();
  baseArray[2] = new SubTypeB();

things get interesting. The code compiles without any problems (as in C#) but when executed, one is faced with an java.lang.ArrayStoreException. The cause for this is burried in the Java Language Specification 4.6 (thanks for the hint in the posts comments which saved me some searching). Upon compilation the type of the array is BaseType and after that it gets the SubTypeA-array assigned. The compiler does not know at this position that it would have to re-type the array it is assigning to to avoid the problems lying ahead. That's why arrays are also checking their assigned objects at runtime and cause this exception if something invalid occours (as specified in JLS 4.7).

I think that this problem would be solvable in Java, C# and most other languages which treat arrays the same way. But I also think that this would open a pandoras box ful of problems and complexity arising from this new constraint just for this specific issue. And personally I think this issue is not a common one and appears just in border-cases so that most developers can deal with it for now. Nevertheless I also think, this issue can be solved, it just may be too late for Java and C#.


What I meant recently with "Never use throw-declaration in C++" is following:

int throwing(int i) throw (exception_A)
  if(i > 0)
    throw exception_B;
  return i;

When compiling on ie. AIX no error is shown during compiling, but if the exception_B gets ever thrown, it magically converts into an uncatchable unknown_exception and crashes your app. I'm not sure if Linux also makes it uncatchable, but there are also no signs of dangers there during compiling.

Microsoft's Visual Studio ships around this elegantly: It just ignores any throw()-declaration everywhere.

I understand why no compiler enforces this to be correct, because of compatibility with old code and huge catch-statements with bad exception-derivates, but I don't know why no compiler has even an option to enforce the correctness of throw-declarations. This would save many people much headache when porting software between platforms.