C# preprocessor directives #pragma exception "disable" "MyException" <<< new

[srburton]

It would be interesting if you had a way to ignore exception without needing the try {} cath (Exception) {} By putting this policy.

 public Main(){
      
    #pragma exception disable MyException
     var value = Validate("string is valid?");
     #pragma exception disable MyException
    
     if(value is string)
      {
         ///....
      }
 }

 public string Validate(string value)
 {    
         throw new MyException("String invalid!");
 }

[YairHalberstadt]

Presumably the second #pragma was meant to be enable?

I understand it would be interesting, but what advantage would it provide?

[franchyd]

This would essentially be a syntactic sugar for

   try
   { 
      Validate();
   }
   catch (MyException) 
   {
   } 

As exceptions are runtime beasts and preprocessor directives are not. I'm not sure why you would need this. Or why you would do it with preprocessor directives.

[HaloFour]

This would codify and encourage very poor exception handling practices.

Even if this functionality were added your example still couldn't compile as value could never be considered definitely assigned.

[srburton]

@HaloFour
This was a simple example to be easy to understand follows a practical example

Situation number 1

 public Main(){
      

     #pragma exception disable MyException
     var value = Validate("c# is good!");
     #pragma exception disable MyException
    
     if(value is string)
      {
         Console.Write(value);
      }
    
    //My code keeps running ....
     

 }

 public string Validate(string value)
 {    
        if(value != "c# is good!")
       {
               throw new MyException("String invalid!");
        }
     return  "Hello Word";
 }
//Output 
Hello Word

Situation number 2

 public Main(){
      
     try{
  
     var value = Validate("c# is good!"); 
  
     if(value is string)
      {
         Console.Write(value);
      }
      else
      {
           Console.Write("Invalid!");
       }

      //My code does not continual:-(

     }cath(Exception e)
     {
        Console.Write(e.Message);
     }
     //Continue code ...
   
     try{
           ///Another treatment block 
       }
        cath(Exception)
       {

       }

     
 }

 public string Validate(string value)
 {    
        if(value == "c# is good!")
       {
               throw new MyException("String invalid!");
        }
     return  "Hello Word";
 }

//Output 
String invalid!

Conclusion

[HaloFour]

@srburton

The C# compiler can't stop exceptions from happening. At most it could silently handle the exceptions at the call-site. This behavior that you're requesting would be impossible to accomplish without CLR changes, and considering that it effectively breaks every rule that exists regarding good exception handling that's certainly never going to happen.

[Austin-bryan]

@srburton I'm curious as to why you think C# should add a feature that will allow for horrible horrible coding practices and lead to even more bugs.

#pragma disable exception
int x = GetX();
#pragma enable exception

The exception would've been thrown, but the #pragma disabled it. So what is the value of x now? is it 0, null (even though it's not nullable), what else could it be? Or, is x` even defined anymore? This will only cause more problems in an excuse for lazy programming.

[srburton]

@HaloFour
I am pleased he handle the exception silently, we have to think so the language has to be the broadest in itself and let the programmer decide whether to use or not just a sugar as the keyword, if this function already deal silently without needing a try /cath and the code keep spinning would be great,

[srburton]

@willard720 The value of the variable would be null

[yaakov-h]

So any not-definitely-assigned variable has a value of default(T)? This sounds like a great vector for bugs.

[bondsbw]

I believe #1151 would provide the framework for a much better approach:

Suppress<MyException>
{
    var value = Validate("string is valid?");
    if(value is string)
    {
        Console.Write(value);
    }
}

elsewhere...

public static void Suppress<TException>(Action a) where TException : Exception
{
    try { a(); }
    catch (TException) {}
}

[markusschaber]

I don't see any reason to invent syntactic sugar via pragmas for what is already available in the language by using try ... catch. It's a rare use case to really do nothing (in most cases, you will in fact want to at least log the exception, at least on trace / verbose levels), and they're better written out explicitly.

Even, the two #pragmas are more to type than the existing try ... catch construct... 👎

[stuartstein777]

@willard720 The value of the variable would be null

It's an int...

[masonwheeler]

Is this dependent on another proposal that I haven't seen yet, to add a try/cath construct to the language? 😛

[jveselka]

You can write yourself a helper method

public TOut TryOrDefault<TException, TOut>(Func<TOut> func) where TException : Exception
{
    try {
        return func();
    } catch (TException) {
        return default;
    }
}

Usage does not look that bad compared to pragmas. It could be even improved a bit by #1349

var value = TryOrDefault<MyException, string>(() => Validate("string is valid?"));

[srburton]

My idea of #pragma it would be because I like c # developer should have full control the language can't stop me, disable functions that in my business suit not alias rule c # should have a form in run mode can create primitive types and tam bém preprocessor directives so linguem be fully templatable, leave the default the uptight to framework, I love developing hack, virus, spam, and with the c # runtime making it possible to mold that would be an enormous advance as the extension that was a great fucker, now imagine the power of programming c # behavior with the own c # code time. Thinking not in an MVC project or Windows Form more in specific projects and can create .dll that contains these mutants of behavior, this may came to security problem and not rely too much on nuget can get around with signatures that have .dll code that might interfere with the c # mode thinking that it would be interpresantes to disable some features and Frameworks visual ja talk that the framework of support, would be very similar to the operator more with everything from c #.

[franchyd]

I'm also not sure that a well defined implementation of this is even possible. It would need to function as a sort of code generation automatically inserting try-catches but as @HaloFour mentioned any variables declared in these sections would throw wrenches into generating valid code. And even if it could generate valid code, it would be exceedingly difficult for the code following these sections to operate without error considering the unknown state of the variables.

[YairHalberstadt]

To my mind a #pragma disable exception would do more than just add a try catch clause.

It would require a runtime change that would ignore any exception being thrown, and just continue execution straight on.

So call Math.Sqrt on a negative number? It'll loop forever.

Pass an index to an array that's greater than the length of the array? You access some random uninitialised data.

In other words, this is one of the stupidest, most dangerous ideas I have ever seen. And completely infeasible as well.

[cinnamonwolfy]

in other words, he wants to drop the sharp from csharp

...

i will show myself out

[masonwheeler]

@YairHalberstadt On Error Resume Next ?

[srburton]

As we can see in this case it would be nice to give a ignore exception at IDE level because it is a controllable error.

[franchyd]

Are you suggesting you just want to disable debugger breakpoints for exceptions within your segments?

[srburton]

Yes, I want to because I already have treatment on my cath right down then that ignore would throw the exception for the previous treatment...

[CyrusNajmabadi]

@srburton i can't parse that. Can you repeat what you're trying to say?

[CyrusNajmabadi]

You're in a delegate. The surrounding try/catch has no bearing on what goes on in that delegate.

[srburton]

Now that I'm in time to explain my idea would be basically this that from the beginning I want to communicate.

[CyrusNajmabadi]

@srburton i have no idea how that would work. Why would the first exception go to the first catch block, and the second exception would go to the second catch block?

[srburton]

This is the normal situation that we all know today, I did a treatment with an alert ja and when I give an exception within a delegate that execption of a warning in Visual Studio the #pragma would be to disable this warning that Visual Studio and continue the Code because it is an exception that has already been handled

Sugestion:

[srburton]

When placed #pragma he simply ignores continues because he knows he has a treatment before breaking the code.

[CyrusNajmabadi]

When placed #pragma he simply ignores continues because he knows he has a treatment before breaking the code.

I don't know what this means at all. What does it mean to "ignores continues"...

This is the normal situation that we all know today, I did a treatment with an alert ja and when I give an exception within a delegate that execption of a warning in Visual Studio the #pragma would be to disable this warning that Visual Studio and continue the Code because it is an exception that has already been handled

If you want to disable things then uncheck this:

You may also want to uncheck:

--

Your complaints seem to be entirely about the debugger and how it works. They dont' seem to have any connection to the language at all.

[franchyd]

I think he wants a #pragma to disable the debugger breaking on exceptions in certain code paths.

[CyrusNajmabadi]

@srburton Debugger requests can be made over at dotnet/roslyn. This doesn't appear to actually involve any sort of language change.