Sometimes feel like a try catch block is just an extra scope around an already existing scope.
Original:
public void Method()
{
try
{
// do something
...
}
catch (CustomException e)
{
DoSomethingWithCustomException(e);
}
catch (Exception e)
{
DoSomethingWithException(e);
}
}
Simplified:
public void Method()
{
// do something
...
catch (CustomException e) => DoSomethingWithCustomException(e);
catch (Exception e) => DoSomethingWithException(e);
}
In my opinion the "try" part of the block is meaningless if you use it for the entire scope. And you can use the original syntax beside this. This syntax can be useful in foreach or any other loop.
So is it possible enable a syntax like this?
So is it possible enable a syntax like this?
Not in the current version of C#. You can always suggest a language feature here, but first search the existing proposals to see if it's been proposed already.
A quick search for "catch" in the issues led to this almost identical proposal:
https://github.com/dotnet/csharplang/issues/908
Note that it has 1 upvote and 15 downvotes. There's only one comment on it, but it gives at least some feedback as to the viability of the feature.
You might also look at third-party libraries like PostSharp that can inject exception handling at a method level.
I am looking for two things here:
I am looking for a list of possible exceptions that EF throws when there are issues. I thought this post would give me what I want, but it only shows the parent.
I secondly plan on converting these Exceptions to HttpStatusCodes that we can act on (display good messages to the user) for what happened.
catch (NotFoundException exception)
{
return HttpStatusCode.NotFound;
}
catch (TimeoutException exception)
{
return HttpStatusCode.RequestTimeout;
}
Is there a list of the exceptions available?
Does Something like the exception converter exist?
I don't think there's anything documented fully. But luckly, EF is open source, so you can simply download the solution and filter in your Solution Explorer on anything that ends with Exception.
It would look like this:
I presume this will cover most of them.
If you do go through with the Exception2StatusCode, definitely make it available somewhere for others to use :)
We have a requirement of parsing/validating a large number of rows read from CSV or Excel files. We read the row and apply business rules to check if all the cells/columns contain the valid data.
The application should keep validating records/columns till end even if some error occurs at an error or column. Currently we are going like this:
private void ValidateRow(RowObject obj)
{
try
{
foreach(var col in obj.Cells)
{
ValidateColumn(col);
}
}
catch(Exception ex)
{
//LOG ERROR
}
}
The columns are validates like this:
public void ValidateColumn(ColumnObject c)
{
try
{
//validate c
}
catch(Exception e)
{
//LOG Column Error
}
}
We are handling error at two places when validating rows (ValidateRow) and then for each column (ValidateColumn). My question is whether this is valid or optimal way of handling error or something more optimal be done?
Since we don't know your Business logic it's difficult to tell. But I would recommend to evaluate all possible exceptions and handle them in different catch blocks. This enables you to handle errors more specific. A good hint is to use Microsofts StyleCop and FxCop. They help you to write good code. In this case they would tell you to not catch general Exceptions.
I think your way is very correct and optimal. If you want to keep going, you should always have a try/catch inside the foreach. But I guess you don't really need the outer try/catch in this case as it will only fail if obj or obj.Cells is null. Unless you have posted only part of your code. Though I agree with comments that validation should not throw exception in the first place but if you are using some 3d party library or any complex code that you are not sure of, it's better to handle it the way you did.
Just curious: Why is the syntax for try catch in C# (Java also?) hard coded for multiple statements? Why doesn't the language allow:
int i;
string s = DateTime.Now.Seconds % 2 == 1 ? "1" : "not 1";
try
i = int.Parse(s);
catch
i = 0;
The example is for trivial purposes only. I know there's int.TryParse.
Consider the fact that there are really three (or more) code blocks in play here:
try {}
catch (myexcption)
{}
catch (myotherexception)
{}
finally
{}
Keep in mind that these are in the scope of a larger context and the exceptions not caught are potentually caught further up the stack.
Note that this is basically the same thing as a class construct that also has the {} structure.
Say for instance you might have:
try
try
if (iAmnotsane)
beatMe(please);
catch (Exception myexception)
catch (myotherexception)
logerror("howdy")
finally
NOW does that second catch belong to the first or the second try? What about the finally? SO you see the optional/multiple portions make the requirement.
UPDATE: This question was the subject of my blog on December 4th, 2012. There are a number of insightful comments on the blog that you might also be interested in. Thanks for the great question!
As others have noted, the proposed feature introduces ambiguities that are confusing. I was interested to see if there were any other justifications for the decision to not support the feature, so I checked the language design notes archive.
I see nothing in the language design notes archive that justifies this decision. As far as I know, C# does it that way because that's how other languages with similar syntax do it, and they do it that way because of the ambiguity problem.
I did learn something interesting though. In the initial design of C# there was no try-catch-finally! If you wanted a try with a catch and a finally then you had to write:
try
{
try
{
XYZ();
}
catch(whatever)
{
DEF();
}
}
finally
{
ABC();
}
which, not surprisingly, is exactly how the compiler analyzes try-catch-finally; it just breaks it up into try-catch inside try-finally upon initial analysis and pretends that's what you said in the first place.
More or less, this is a play on the dangling else problem.
For example,
if( blah )
if ( more blah )
// do some blah
else
// no blah I suppose
Without curly braces, the else is ambiguous because you don't know if it's associated with the first or second if statement. So you have to fallback on a compiler convention (e.g. in Pascal or C, the compiler assumes the dangling else is associated with the closest if statement) to resolve the ambiguity, or fail the compile entirely if you don't want to allow such ambiguity in the first place.
Similarly,
try
try
// some code that throws!
catch(some blah)
// which try block are we catching???
catch(more blah )
// not so sure...
finally
// totally unclear what try this is associated with.
You could solve it with a convention, where catch blocks are always associated with the closest try, but I find this solution generally allows programmers to write code that is potentially dangerous. For example, in C, this:
if( blah )
if( more blah )
x = blah;
else
x = blahblah;
...is how the compiler would interpret this if/if/else block. However, it's also perfectly legitimate to screw up your indenting and write:
if( blah )
if( more blah )
x = blah;
else
x = blahblah;
...which now makes it appear like the else is associated with the outer if statement, when in fact it is associated with the inner if statement due to C conventions. So I think requiring the braces goes a long way towards resolving ambiguity and preventing a rather sneaky bug (these sorts of issues can be trivial to miss, even during code inspection). Languages like python don't have this issue since indentation and whitespace matter.
If you assume that the designers of C# simply choose to use the same syntax as C++ then the question becomes why are braces necessary with single statements try and catch blocks in C++. The simple answer is that Bjarne Stroustrup thought the syntax was easier to explain.
In The Design and Evolution of C++ Stroustrup writes:
"The try keyword is completely redundant and so are the { } braces except where multiple statements are actually used in a try-block or a handler."
He goes on to give an example where the try keyword and { } are not needed. He then writes:
"However, I found this so difficult to explain that the redundancy was introduced to save support staff from confused users."
Reference:
Stroustrup, Bjarne (1994). The Design and Evolution of C++. Addison-Wesley.
The first think I can think of is that the curly braces create a block with its own variable scope.
Look at the following code
try
{
int foo = 2;
}
catch (Exception)
{
Console.WriteLine(foo); // The name 'foo' does not exist in the current context
}
foo is not accessible in the catch block due to the variable scoping. I think this makes it easier to reason about whether an variable has been initialized before use or not.
Compare with this code
int foo;
try
{
foo = 2;
}
catch (Exception)
{
Console.WriteLine(foo); // Use of unassigned local variable 'foo'
}
here you can not guarantee that foo is initialized.
try // 1
try // 2
something();
catch { // A
}
catch { // B
}
catch { // C
}
does B catches try 1 or 2?
I don't think you can resolve this unambiguously, since the snippet might mean:
try // 1
{
try // 2
something();
catch { // A
}
}
catch { // B
}
catch { // C
}
try // 1
{
try // 2
something();
catch { // A
}
catch { // B
}
}
catch { // C
}
Probably to discourage overuse. A try-catch block is big and ugly, and you're going to notice when you're using it. This mirrors the effect that a catch has on your application's performance - catching an exception is extremely slow compared to a simple boolean test.
In general you should avoid errors, not handle them. In the example you give, a much more efficient method would be to use
if(!int.TryParse(s, out i))
i=0;
The rational is that it's more maintainable (easier to change, less likely to break, ergo higher quality):
it's clearer, and
it's easier to change because if you need to add a line to your blocks you don't introduce a bug.
As to why exception handling is different than conditional expressions...
If/Else is conditional upon an expression to use one of two (or more If/Else if/Else) paths in the code
Try/Catch is part of exception handling, it is not a conditional expression. Try/Catch/Finally operates only when an exception has been thrown inside the scope of the Try block.
Exception handling will traverse up the stack/scope until it finds a Catch block that will catch the type of exception that was thrown. Forcing scope identifiers makes this check for blocks simplified. Forcing you to scope when dealing with exceptions seems like a good idea, it also is a good indication that this is part of exception handling rather than normal code. Exceptions are exceptions, not something you really want happening normally but know can happen and want to handle when they do happen.
EDIT: There is one more reason which I can think of, is that CATCH is mandatory after a TRY unlike ELSE. Hence there needs to be definite way to define the TRY block.
Another way of looking at this…
Given all the maintenance problem that have been created by “if”, “while”, “for” and “foreach” statements without bases, a lot of companies have coding standards that always require bases on statements that act on a “block”.
So they make you write:
if (itIsSo)
{
ASingleLineOfCode();
}
Rather then:
if (itIsSo)
ASingleLineOfCode();
(Note as indenting is not checked by the compiler, it can't be depended on to be right)
A good case could be made for designing a language that always require the bases, but then too many people would have hated C# due to having to always use the bases. However for try/catch there was not an expectation of being able to get away without using the bases, so it was possible to require them without to many people complaining.
Given a choose I would much rather have if/endIf (and while/endWhile) as the block delimiters but the USA got its way on that one. (C got to define what most languages look like rather than Module2, afterall most of what we do is defined by history not logic)
The simplest (I think) answer is that each block of code in C/C++/C# requires curly braces.
EDIT #1
In response to negative votes, directly from MSDN:
try-catch (C# Reference)
The try-catch statement consists of a try block followed by one or more catch clauses, which specify handlers for different exceptions.
As per definition says, it is a block, so it requires curly braces. That is why we cannot use it without { }.
I'm new to Resharper and I'm trying to understand why it seems to suggest:
catch (Exception) { }
for
catch { }
and
catch { }
for
catch (Exception) { }
I'm baffled.
Basically it's offering you a way of switching between the two alternatives, rather than making a concrete recommendation of which is better.
You can change what's offered under ReSharper / Options / Code Inspection / Inspection Severity - find the relevant option and change the priority between none, hint, suggestion, warning or error.
Resharper does have another message that is more of a recommendation: it advises you not to catch the Exception class.
catch { } <-- supresses all errors. we should do, only if we are sure to discard any error.
catch { throw; } <-- This is not required. It is already taken care by compiler to rethrow the error to calling function. It is not required to add explicitly.
It's just giving you alternatives to consider, which may spark some insight into improving your code. Just ignore the suggestion if it doesn't make sense.
Because sometimes when tidying catch blocks you move to/from catch(Exception ex) to catch(Exception) to catch and vice versa, depending on whether you're trying to purely filter, log/wrap, or swallow the exception. (See me requesting the same feature for CodeRush without being aware it even existed in R#)
IIRC there may also be a difference between the two from the point of view of the code they generate/things they filter and miss
EDIT: The link was previously labelled "Empty catch is bad" hence very correct downvotes!