Editing Comparison of C Sharp and Java (section)

=== Exceptions ===
{| class="wikitable" style="width:80%;"
|-
! style="width:40%;"| Exceptions !! style="width:30%;"|Java !! style="width:30%;"|C#
|-
|Checked exceptions || {{yes}} || {{no}}
|-
|Try-catch-finally || {{yes}} || {{yes}}
|-
|Exception filters || {{no}} || {{yes}}<ref>{{cite web |url=https://www.pluralsight.com/guides/exceptional-exception-filtering |title=Exceptional Exception Filtering |publisher=Pluralsight® |access-date=24 June 2022}}</ref>
|}

====Checked exceptions====
Java supports [[checked exceptions]] (along with unchecked exceptions). C# only supports unchecked exceptions. Checked exceptions force the programmer to either declare the exception thrown in a method, or to catch the thrown exception using a {{tt|try-catch}} clause.

Checked exceptions can encourage good programming practice, ensuring that all errors are dealt with. However [[Anders Hejlsberg]], chief C# language architect, argues that they were to some extent an experiment in Java and that they have not been shown to be worthwhile except in small example programs.<ref>{{cite web |url=http://www.artima.com/intv/handcuffs.html |title=The Trouble with Checked Exceptions |publisher=Artima.com |access-date=24 February 2015}}</ref><ref>{{cite web |url=http://msdn2.microsoft.com/en-us/vcsharp/aa336812.aspx |title=Msdn forums – Visual C# Language |publisher=Msdn2.microsoft.com |access-date=24 February 2015 |archive-url=https://web.archive.org/web/20070320060200/http://msdn2.microsoft.com/en-us/vcsharp/aa336812.aspx |archive-date=20 March 2007 |url-status=dead}}</ref>

One criticism is that checked exceptions encourage programmers to use an empty catch block ({{java|catch (Exception e) {}|}}),<ref name=bruceeckel>{{cite web |last=Eckel |first=Bruce |url=http://www.mindview.net/Etc/Discussions/CheckedExceptions |title=Does Java need Checked Exceptions? |access-date=6 December 2012 |archive-url=https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions |archive-date=5 April 2002 |url-status=dead }}</ref> which silently swallows exceptions, rather than letting the exceptions propagate to a higher-level exception-handling routine. In some cases, however, [[exception chaining]] can be applied instead, by re-throwing the exception in a wrapper exception. For example, if an object is changed to access a database instead of a file, an {{Javadoc:SE|java/sql|SQLException}} could be caught and re-thrown as an {{Javadoc:SE|java/io|IOException}}, since the caller may not need to know the inner workings of the object.

However, not all programmers agree with this stance. James Gosling and others maintain that checked exceptions are useful, and misusing them has caused the problems. Silently catching exceptions is possible, yes, but it must be stated explicitly what to do with the exception, versus unchecked exceptions that allow doing nothing by default. It can be ignored, but code must be written explicitly to ignore it.<ref>{{cite web |url=http://www.artima.com/intv/solid.html |title=Failure and Exceptions |publisher=Artima.com |date=22 September 2003 |access-date=18 August 2013}}</ref><ref>{{cite web |url=http://www.shaunabram.com/checked-exceptions-article/ |title=Checked Exceptions |publisher=Shaun Abram |access-date=18 August 2013}}</ref>

====Try-catch-finally====
There are also differences between the two languages in treating the {{code|try-finally}} statement. The {{mono|finally}} block is always executed, even if the {{mono|try}} block contains control-passing statements like {{mono|throw}} or {{mono|return}}. In Java, this may result in unexpected behavior, if the {{mono|try}} block is left by a {{mono|return}} statement with some value, and then the {{mono|finally}} block that is executed afterward is also left by a {{mono|return}} statement with a different value. C# resolves this problem by prohibiting any control-passing statements like {{mono|return}} or {{mono|break}} in the {{mono|finally}} block.

A common reason for using {{code|try-finally}} blocks is to guard resource managing code, thus guaranteeing the release of precious resources in the finally block. C# features the {{mono|using}} statement as a syntactic shorthand for this common scenario, in which the {{code|Dispose()}} method of the object of the {{mono|using}} is always called.

A rather subtle difference is the moment a [[stack trace]] is created when an exception is being thrown. In Java, the stack trace is created in the moment the exception is created.

<syntaxhighlight lang=Java>
class Foo {
    Exception up = new Exception();
    int foo() throws Exception {
        throw up;
    }
}
</syntaxhighlight>

The exception in the statement above will always contain the constructor's stack-trace – no matter how often foo is called.
In C# on the other hand, the stack-trace is created the moment "throw" is executed.

<syntaxhighlight lang="csharp">
class Foo
{
    Exception e = new Exception();

    int foo()
    {
        try
        {
            throw e;
        }
        catch (Exception e)
        {
            throw;
        }
    }
}
</syntaxhighlight>

In the code above, the exception will contain the stack-trace of the first throw-line. When catching an exception, there are two options in case the exception should be rethrown: {{mono|throw}} will just rethrow the original exception with the original stack, while {{code|throw e}} would have created a new stack trace.

==== Finally blocks ====
Java allows flow of control to leave the {{mono|finally}} block of a {{mono|try}} statement, regardless of the way it was entered. This can cause another control flow statement (such as {{mono|return}}) to be terminated mid-execution. For example:

<syntaxhighlight lang="java">
int foo() {
    try {
        return 0;
    } finally {
        return 1;
    }
}
</syntaxhighlight>

In the above code, the {{mono|return}} statement within the {{mono|try}} block causes control to leave it, and thus {{mono|finally}} block is executed before the actual return happens. However, the {{mono|finally}} block itself also performs a return. Thus, the original return that caused it to be entered is not executed, and the above method returns 1 rather than 0. Informally speaking, it ''tries'' to return 0 but ''finally'' returns 1.

C# does not allow any statements that allow control flow to leave the {{mono|finally}} block prematurely, except for {{mono|throw}}. In particular, {{mono|return}} is not allowed at all, {{mono|goto}} is not allowed if the target label is outside the {{mono|finally}} block, and {{mono|continue}} and {{mono|break}} are not allowed if the nearest enclosing loop is outside the {{mono|finally}} block.