Why doesn't C# have checked exceptions?

Why doesn't C# have checked exceptions?

Rate This
  • Comments 11

Checked exceptions are a very hotly debated topic in some circles, particularly for experienced Java developers moving to, or additionally learning, C#. Here are some resources that discuss the issue in depth:

Note that without the CLR itself supporting checked exceptions, it would be effectively impossible for C# to do so alone.

[Author: Jon Skeet]

Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post
  • AFAIK is the Java compiler that enforces checked exceptions and not JVM. You can emit byte code that will totally ignore any checked exception.

    So (in theory), the C# compiler could behave exactly as Java (using some special attributes)

    but IMHO leaving checked exceptions out of C# and CLR was an excellent choice.
  • From an Email conversation this evening: what do you think about it? For a while, I was "all flame" about Checked exceptions, but then I read about their limitations (which are why they aren't included in C#, more about it there :

  • using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Text;

    namespace polymorphisum


       class A


           public virtual void show()


               Console.WriteLine("Base Class function");



       class b : A


           public virtual void show()


               Console.WriteLine("Drived Class function");



       class c : b


           public override void show()


               Console.WriteLine("C Class function");


           static void Main(string[] args)


               c c1 = new c();





        * A C1 = new C();

        * Question 1. How to Call C Class Show Function in this Condition

        * Question 2. How to Call B Class Show Function in this Condition

        * Question 3. Why Alway Call A Class Show Function in this Condition. if i give virutal keyword or not

        * -------------------------------------------------------------------------

        * Second Senario

        * B C1 = new C();

        * Question 1. How to Call A Class Show()/Function in this Condition

        * Question 2. Why C Class  Show()/function Call here

        * Question 3. Why B Class Show()/function Call if i have A Class show() and both in class i am use virtual keyword means

        * why not call A Class Show()/Function

        * --------------------------------------------------------------------------

        * Thired  Senario

        * C C1 = new C();

        * Question 1. Why Alway call C Class Show()/Function if am useing or not use the override keyword

        * Question 2. How to Call A Class Show()/Function in this Condition

        * Question 3. How to Call B Class Show()/Function in this Condition


        * Give me answer on Himanshu888.sharma@gmail.com or Himanshu888.sharma@facebook.com

        * thanx in advance




  • protected void AddRecord(object sender, EventArgs e)


           float CalculatedQty = Int64.Parse(TextBox4.Text);

           float PhysicalQty = Int64.Parse(txt1.Text);

           DateTime StTakdt = Convert.ToDateTime(txtdt1.Text);

           bal pBAL = new bal();

           int intResult = 0;



               intResult = pBAL.Insert5(int.Parse(TextBox5.Text), int.Parse(TextBox2.Text), CalculatedQty, PhysicalQty, StTakdt);

               if (intResult > 0)

                   lbl.Text = "Record Insert Successfully.";


                   lbl.Text = lbl.Text = "AuditID [<b>" + TextBox5.Text + "</b>] alredy exists, try another name";

               throw new Exception("plz enter detail");


           catch (Exception ee)


               Console.WriteLine("{0} Exception caught plz enter detail.", ee);

               lbl.Text = ee.Message.ToString();




               pBAL = null;


           gvdetails.EditIndex = -1;

           // Refresh the list



    i click on add button  without inserting anything it will throw exception plz enter detail

  • "Note that without the CLR itself supporting checked exceptions, it would be effectively impossible for C# to do so alone."

    No it wouldn't. You could have a CheckedException class that inherits from Exception, and then run a compile time check to see if any CheckedExceptions that may be thrown are caught. Although I'm more of the opinion that the ideal set-up is to note exceptions that may be thrown in the documentation and fire warnings then those exceptions aren't either caught or redeclared in the documentation. Checked exceptions ala Java either force you to restrict yourself to the exceptions you originally declared, or break code that calls a method that may throw an exception.

  • I just realised that that comment I made was on a decade-old article xD

  • The basic design philosophy of C# is that actually catching exceptions is rarely useful, whereas cleaning up resources in exceptional situations is quite important. I think it's fair to say that using (the IDisposable pattern) is their answer to checked exceptions



  • The biggest problem with .Net and C# is that the majority of developers don't seem to write code that deals with input from outside sources or with data that is otherwise probable to not be valid.

    What checked exceptions are about, is knowing when to handle specific types of problems that the developer is not in control of.  For example, when creating a socket connection in the C language, you need to check for -1 return values from the socket() call, from the bind() call from the listen() call the accept() call and/or connect() call.

    In Java, all of those behaviors are encapsulated into a different API that has do with simplifying program logic by allowing the developer to write less code.  So, you would use the fact that IOException and the subclass SocketException are checked exceptions, to understand that the connection may not always work correctly.  So, you are forced, by checked exception requirements, to provide code to deal with that case.

    In .Net, without checked exceptions, developers must spend a lot more time reading and rereading documentation for APIs or using IDE assistance to be reminded out the APIs work.

    The worst part about C# exception handling, is that programs throwing exceptions that should be checked exceptions can end up being terminated by these exceptions.

    Have you ever been using a windows application and had it just disappear from the screen with loss of data or context?  That's an uncaught exception most likely.

    The reason why c# designers did not include checked exceptions seems more like a cop out and lack of true understanding of how good software systems are designed.

    Yes, you can just throw exception catching all over your code and hope it will never exit inadverently, but it would be much more user and developer friendly if developers were reminded when there could be a problem that they needed to handle, so that they had to deal with it.

    Instead, today, we have this 'test until it's perfect' mantra which assumes all to readily that testing can be perfect and provide all the probable inputs that might need to be handled correctly.  That never happens 100%, and that's one of the predominate reasons why Microsoft regularly ends up on the CERT security lists with the same applications having the same kind of failure modes that open them to allowing remote systems to cause your computer to execute arbitrary code.

Page 1 of 1 (11 items)