How can I handle an expected exception?
I have code in my MVC controller that calls the following:
u.RowKey == new SimplerAES().Dec(HttpServerUtility.UrlTokenDecode(id)));
In my other SimplerAES class:
public string Dec(byte[] encrypted)
{
return encoder.GetString(Decrypt(encrypted));
}
public byte[] Decrypt(byte[] buffer)
{
try {
MemoryStream decryptStream = new MemoryStream();
using (CryptoStream cs = new CryptoStream(decryptStream, decryptor, CryptoStreamMode.Write))
{
cs.Write(buffer, 0, buffer.Length);
}
return decryptStream.ToArray();
} catch(CryptographicException e){
//... do something with it ...
return null; // I put the return null here as I got a syntax message saying
// not all code returns
}
}
Can someone please explain how I get the message that decrypt failed all the way up
to the point where I first try to get the RowKey. Do I have to put u.RowKey within
a try catch as well?
Just don't catch the exception in your method, unless you really need the "do something" part. If you don't catch the exception, it will bubble up the stack until there's code which does catch it.
If you do need to do something within that method, such as logging, you can catch the exception and rethrow it within your catch block using
throw;
Note that this is preferred over
throw e;
as the latter will rewrite the stack trace. It probably won't make much difference in this particular case, but it's worth being aware of.
I suggest you ignore cryptography for the moment, and go hunting for good articles or books on exception handling in C#. This MSDN page is probably a good starting point.
Assuming that you actually need to do something at this level, simply rethrow the exception:
catch (CrypotgraphicException e)
{
// Do something
throw;
}
However, it might be simpler not to catch it at all and let it bubble up higher to your other exception handler.
If you want to continue having the exception unwind the stack don't return null from the catch block. you need to throw (without the exception reference) to continue unwinding with the same exception.
e.g.
try
{
// Do stuff
}
catch(CryptographicException e)
{
// Do stuff to clean up
throw;
}
If you throw e (which has the existing exception object) you destroy some of the stack trace data which makes it less useful. If you want to add more information, wrap the existing exception in a new exception (as the InnerException) and then throw the new exception object. That way you preserve the full exception information.
try
{
// Do stuff
}
catch(CryptographicException e)
{
// Do stuff to clean up
Exception newEx = new Exception("Some further message", e);
throw newEx;
}
Note: Don't simply create the base Exception object, you should derive a new exception class from an existing base (if a suitable Exception class is not available) and use the derived version. This makes catching much easier because you can then catch the exact type you need and not have to have your catch block figure out what do do because you are throwing overly broad exceptions.
Only ever catch an exception if there is something useful you can do with it. Simply swallowing it an returning null in your Decrypt method is not useful. Instead, let the exception bubble up until it gets to a point where it can be usefully handled..
Do I have to put u.RowKey within a try
catch as well?
This would be a more appropriate place to catch the exception...
Related
I'm a beginner programmer and I have been faced with exceptions recently. I've done this small test below and the output I received was not the same as the one I expected.
static void Main(string[] args)
{
ushort var = 65535;
try
{
checked { var++; }
}
catch (OverflowException)
{
Console.WriteLine("Hello!");
throw;
}
catch
{
Console.WriteLine("Here I am!");
}
}
I was expecting the program to do the following:
Try to var++, fail and create an OverflowException;
Enter Catch (OverflowException) and write "Hello!";
Throw an Exception and enter catch;
Write "Here I am!".
However, I only got on screen "Hello!".
EDIT: Thanks to those who commented. I think I'm starting to understand. However, my confusion originated because of this book I'm reading: C# 4.0.
I could show the text, however it is in Portuguese. I'm going to translate what it says: "Sometimes it is useful to propagate the exception through more than one catch. For example, let's suposse it is necessary to show a specific error message due to the fact that the "idade" is invalid, but we still need to close the program, being that part in the global catch. In that case, it is necessary to propagate the exception after the execution of the first catch block. To do that, you only need to do a simple throw with no arguments."
Example from the book
In this example of the book you can see the programmer do the same thing I did. At least it looks like it. Am I missing something? Or is the book wrong?
Hope you can help me. Thanks!
In short, you are doing it wrong. Let's visit the documentation
Exception Handling (C# Programming Guide)
Multiple catch blocks with different exception filters can be chained
together. The catch blocks are evaluated from top to bottom in your
code, but only one catch block is executed for each exception that
is thrown.
Although it doesn't specifically say you can't catch an exception that has been re-thrown in an exception filter, the fact is you can't. It would be a nightmare and have complicated and unexpected results.
That's all to say, you will need another layer (inner or outer) of try catch to catch the exception that is thrown in catch (OverflowException)
You'll get the output you expected if you nest try/catch blocks:
static void Main(string[] args)
{
try
{
ushort var = 65535;
try
{
checked { var++; }
}
catch (OverflowException)
{
Console.WriteLine("Hello!");
throw;
}
}
catch
{
Console.WriteLine("Here I am!");
}
}
I have two articles on exception handling I link often. I personally consider them required reading when dealing with them:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET
As for this case, you are not throwing a exception. You are re-throwing one you caught. Think of it like a fisherman doing "catch and release". It can be used for some scenarios, like this time I wrote a TryParse replacement for someone stuck on .NET 1.1:
//Parse throws ArgumentNull, Format and Overflow Exceptions.
//And they only have Exception as base class in common, but identical handling code (output = 0 and return false).
bool TryParse(string input, out int output){
try{
output = int.Parse(input);
}
catch (Exception ex){
if(ex is ArgumentNullException ||
ex is FormatException ||
ex is OverflowException){
//these are the exceptions I am looking for. I will do my thing.
output = 0;
return false;
}
else{
//Not the exceptions I expect. Best to just let them go on their way.
throw;
}
}
//I am pretty sure the Exception replaces the return value in exception case.
//So this one will only be returned without any Exceptions, expected or unexpected
return true;
}
But as a rule of thumb, you should be using stuff like "finally" blocks for cleanup work rather then catch and release. throw inside a catch block is something you use rarely.
Here is the code that I wrote to understand how exception handling works:
using System;
using System.IO;
class ExceptionHandling
{
public static void Main()
{
try
{
StreamReader streamReader = new StreamReader("C:\\Sample Files\\Data.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
Console.WriteLine(ex.StackTrace);
}
}
}
I understand the try block, but I am having a hard time to understand how catch block works. I know that Exception is a class and ex.Message is the exceptions message.
My questions is what is ex? If this is an object, then how can we use without instantiation? And what does putting Exception ex into parameter of catch do?
And finally are try and catch methods? If they yes, are they in System namespace?
ex is a variable of type Exception.
When code elsewhere fails, it will do something like throw new Exception("some message here");.
The throw keyword causes the exception (created by new) to be passed up the stack, and if it hits your catch, that code will execute with ex pointing to that exception object.
throw, try, and catch are not functions, they are keywords. They're language features like foreach and if.
ex is a variable referring to an exception object that is instantiated by either the object that raised the exception, one of its dependencies, or the .NET runtime.
You can create your own exceptions like any object, and then throw them:
var myException = new MyCustomException(/*...*/);
throw myException;
try-catch is a statement that is part of the syntax of the C# language.
The catch part does not need to reference the exception variable if you do not need to access any of its members in your handling code. The following is valid syntax:
try {
// some code that might throw IO exception
catch (IOException) {
Console.WriteLine("Exception thrown.");
}
Bonus tips:
It is generally bad practice to catch the base class Exception - you should typically catch the most specific derived exception that you are trying to handle in your catch clause.
When you are using a class that implements IDisposable like StreamReader, you should consider using the using statement.
If the code crashes anywhere the it will have because someone has instantiated and thrown (C# throw keyword) an instance of an Exception (most likely a subtype such as InvalidOperationException).
If this exception is raised inside the try, the catch will attempt to handle it by checking if it can be derived from Exception (which all .Net Exceptions do).
If you define a variable to hold the instance of the exception on your catch block the runtime will assign the exception to it.
So ex will be set by the runtime to the exception that occurred. Have a look using the Debugger to see more information about it.
You can handle just specific exceptions like so:
catch (NullReferenceException nre) { HandleNRE(nre); } //nre will be a NullReferenceException
catch (InvalidOperationException ioe) { HandleIOE(ioe); } //ioe will be an InvalidOperationException
catch (Exception e) { HandleEverythingElse(e); } //e will be whatever was thrown.
You can also have catch blocks without an ex, e.g.
catch (NullReferenceException) { /* Do nothing, who cares about nulls. */ }
I have the following code:
try
{
retval = axNTLXRemote.IsUnitPresent(_servers[0].IPAddress, 1, _servers[0].RemotePort, _servers[0].CommFailDelay * 1000);
}
catch (COMException ce)
{
throw ce;
}
Which gives me the followig warning which I want to get rid of:
CA2200 : Microsoft.Usage : 'Connect()' rethrows a caught exception and specifies it explicitly as an argument. Use 'throw' without an argument instead, in order to preserve the stack location where the exception was initially raised.
I have read the following The difference between try/catch/throw and try/catch(e)/throw e and I understand that the 'throw ce; will reset the stack trace and make it appear as if the exception was thrown from that function.
I want to simply change it to a 'throw' instead of a 'throw ce' which will get rid of the warning.
What is the difference in the following catches:
catch (COMException ce)
{
throw;
}
and
catch (COMException)
{
throw;
}
Do I only need to have 'COMException ce' if I wish to somehow use the ce variable?
Also, when I perform a 'throw' or 'throw ce', is it the calling function that will handle or catch it?? I'm a little unclear about this.
The only difference is that with catch (COMException ce), you are assigning the exception to a variable, thereby letting you access it within the catch block. Other than that, it is in every way identical.
I'm not sure what the question is here. If you want to access the exception object, you must give it a variable name in the catch clause.
No matter how or where an exception is thrown, the exception will bubble up through the call stack to the closest catch block that matches.
Here's an example.
void Method1()
{
try
{
Method2();
}
catch // this will catch *any* exception
{
}
}
void Method2()
{
try
{
Method3();
}
catch (COMException ex) // this will catch only COMExceptions and exceptions that derive from COMException
{
}
}
void Method3()
{
// if this code were here, it would be caught in Method2
throw new COMException();
// if this code were here, it would be caught in Method1
throw new ApplicationException();
}
I'm sure someone will jump in with an uber-technical answer, but in my experience the answer to your first two questions is that there is no difference, and as you stated you'd only include ce if you intended to use it to write the stack trace to a log or display the message to the user or similar.
The throw will send the exception up the chain. That may be the calling method or, if your method has several nested try/catch blocks, it will send the exception to the next try/catch block that the current try/catch block is nested within.
Here are a couple good resources to check out if you want to read further on the subject:
Exception Handling
Design Guidelines for Exceptions
There is no difference in both cases, but only when exception variable should be used for stack/message etc.
So:
catch(ComException);
and
catch(ComException ex);
statements will produce similar MSIL, except local variable for ComException object:
.locals init ([0] class [mscorlib]System.Exception ex)
i'm calling a function that throws a custom exception:
GetLockOwnerInfo(...)
This function in turn is calling a function that throws an exception:
GetLockOwnerInfo(...)
ExecuteReader(...)
This function in turn is calling a function that throws an exception:
GetLockOwnerInfo(...)
ExecuteReader(...)
ExecuteReader(...)
And so on:
GetLockOwnerInfo(...)
ExecuteReader(...)
ExecuteReader(...)
ExecuteReaderClient(...)
Fill(...)
One of these functions throws an SqlException, although that code has no idea what an SqlException is.
Higher levels wrap that SqlException into another BusinessRuleException in order to include some special properties and additional details, while including the "original" exception as InnerException:
catch (DbException ex)
{
BusinessRuleExcpetion e = new BusinessRuleException(ex)
...
throw e;
}
Higher levels wrap that BusinessRuleException into another LockerException in order to include some special properties and additional details, while including the "original" exception as InnerException:
catch (BusinessRuleException ex)
{
LockerException e = new LockerException(ex)
...
throw e;
}
The problem now is that i want to catch the origianl SqlException, to check for a particular error code.
But there's no way to "catch the inner exception":
try
{
DoSomething();
}
catch (SqlException e)
{
if (e.Number = 247)
{
return "Someone";
}
else
throw;
}
i thought about catching SqlException right when it's thrown, and copy various values to the re-thrown exception - but that code is not dependant on Sql. It is experiencing an SqlException, but it has no dependency on SqlException.
i thought about catching all exceptions:
try
{
DoSomething(...);
}
catch (Exception e)
{
SqlException ex = HuntAroundForAnSqlException(e);
if (ex != null)
{
if (e.Number = 247)
{
return "Someone";
}
else
throw;
}
else
throw;
}
But that's horrible code.
Given that .NET does not let you alter the Message of an Exception to include additional information, what is the intended mechanism to catch original exceptions?
You need c# 6 / visual studio 2015 in order to do this using a predicate:
catch (ArgumentException e) when (e.ParamName == “…”)
{
}
Official C# Try/Catch Documentation
I hate to have to tell you this, but you cannot catch an inner exception.
What you can do is inspect one.
I suggest you catch your high-level exception (I believe it was LockerException) and inspect the InnerException property of that exception. Check the type, and if it's not a SqlException, check the InnerException of that exception. Walk each one until you find a SqlException type, then get the data you need.
That said, I agree with dasblinkenlight that you should consider -- if possible -- a heavy refactor of your exception framework.
Checking the error code of a wrapped exception is not a good practice, because it hurts encapsulation rather severely. Imagine at some point rewriting the logic to read from a non-SQL source, say, a web service. It would throw something other than SQLException under the same condition, and your outer code would have no way to detect it.
You should add code to the block catching SQLException to check for e.Number = 247 right then and there, and throw BusinessRuleException with some property that differentiates it from BusinessRuleException thrown in response to non-SQLException and SQLException with e.Number != 247 in some meaningful way. For example, if the magic number 247 means you've encountered a duplicate (a pure speculation on my part at this point), you could do something like this:
catch (SQLException e) {
var toThrow = new BusinessRuleException(e);
if (e.Number == 247) {
toThrow.DuplicateDetected = true;
}
throw toThrow;
}
When you catch BusinessRuleException later, you can check its DuplicateDetected property, and act accordingly.
EDIT 1 (in response to the comment that the DB-reading code cannot check for SQLException)
You can also change your BusinessRuleException to check for SQLException in its constructor, like this:
public BusinessRuleException(Exception inner)
: base(inner) {
SetDuplicateDetectedFlag(inner);
}
public BusinessRuleException(string message, Exception inner)
: base(message, inner) {
SetDuplicateDetectedFlag(inner);
}
private void SetDuplicateDetectedFlag(Exception inner) {
var innerSql = inner as SqlException;
DuplicateDetected = innerSql != null && innerSql.Number == 247;
}
This is less desirable, because it breaks encapsulation, but at least it does it in a single place. If you need to examine other types of exceptions (e.g. because you've added a web service source), you could add it to the SetDuplicateDetectedFlag method, and everything would work again.
Having an outer application layer care about the details of a wrapped exception is a code smell; the deeper the wrapping, the bigger the smell. The class which you now have wrapping the SqlException into a dbException is presumably designed to expose an SqlClient as a generic database interface. As such, that class should include a means of distinguishing different exceptional conditions. It may, for example, define a dbTimeoutWaitingForLockException and decide to throw it when it catches an SqlException and determines based upon its error code that there was a lock timeout. In vb.net, it might be cleaner to have a dbException type which exposes an ErrorCause enumeration, so one could then say Catch Ex as dbException When ex.Cause = dbErrorCauses.LockTimeout, but unfortunately exception filters are not usable in C#.
If one has a situation where the inner-class wrapper won't know enough about what it's doing to know how it should map exceptions, it may be helpful to have the inner-class method accept an exception-wrapping delegate which would take an exception the inner class has caught or would "like" to throw, and wrap it in a way appropriate to the outer class. Such an approach would likely be overkill in cases where the inner class is called directly from the outer class, but can be useful if there are intermediate classes involved.
Good question and good answers!
I just want to supplement the answers already given with some further thoughts:
On one hand I agree with dasblinkenlight and the other users. If you catch one exception to rethrow an exception of a different type with the original exception set as the inner exception then you should do this for no other reason than to maintain the method's contract. (Accessing the SQL server is an implementation detail that the caller is not/must not/cannot be aware of, so it cannot anticipate that a SqlException (or DbException for that matter) will be thrown.)
Applying this technique however has some implications that one should be aware of:
You are concealing the root cause of the error. In your example you are reporting to the caller that a business rule was invalid(?), violated(?) etc., when in fact there was a problem accessing the DB (which would be immediately clear if the DbException were allowed to bubble up the call stack further).
You are concealing the location where the error originally occurred. The StackTrace property of the caught exception will point to a catch-block far away from the location the error originally occurred. This can make debugging notoriously difficult unless you take
great care to log the stack traces of all the inner exceptions as well. (This is especially true once the software has been deployed into production and you have no means to attach a
debugger...)
Given that .NET does not let you alter the Message of an Exception to include additional information, what is the intended mechanism to catch original exceptions?
It is true that .NET does not allow you to alter the Message of an Exception. It provides another mechanism however to supply additional information to an Exception via the Exception.Data dictionary. So if all you want to do is add additional data to an exception, then there is no reason to wrap the original exception and throw a new one. Instead just do:
public void DoStuff(String filename)
{
try {
// Some file I/O here...
}
catch (IOException ex) {
// Add filename to the IOException
ex.Data.Add("Filename", filename);
// Send the exception along its way
throw;
}
}
As other peeps say, you cannot catch an the InnerException. A function such as this could help you get the InnerException out of the tree though:
public static bool TryFindInnerException<T>(Exception top, out T foundException) where T : Exception
{
if (top == null)
{
foundException = null;
return false;
}
Console.WriteLine(top.GetType());
if (typeof(T) == top.GetType())
{
foundException = (T)top;
return true;
}
return TryFindInnerException<T>(top.InnerException, out foundException);
}
I agree with the other comments that this is a code smell 🦨 and should be avoided. But if a refactor is not possible you could try something like this...
Create an extension method...
public static bool HasInnerException(this Exception ex, Func<Exception, bool> match)
{
if (ex.InnerException == null)
{
return false;
}
return match(ex.InnerException) || HasInnerException(ex.InnerException, match);
}
And use it like...
catch (Exception ex) when (ex.HasInnerException(e => e is MyExceptionThatIsHidden))
{
...
But really you should be solving for 👇
var exception = new Exception("wrapped exception 3",
new Exception("wrapped exception 2",
new Exception("wrapped exception 1",
new MyExceptionThatIsHidden("original exception")))); // <--- ???
following is a code snippet:
class xxx
{
public xxx(){}
try
{
throw new Exception(InvalidoperationException);
}
catch(Exception x)
{
}
catch(InvalidoperationException x)
{
}
}
can anyone tell which exception will raise here and what is the reason behind it.
Wow, lots of problems here. Where to start?
That code won't compile. The try-catch block that you've defined is outside of any method, which is not allowed. You need to move it inside of a method.
Never throw a method that you intend to catch yourself later in the method. That's commonly known as using exceptions for "flow control", which is roundly discouraged. There is a performance cost associated with doing so, and it also makes it very confusing to monitor the exceptions that are being thrown when using a debugger when you have code that's throwing and catching it's own exceptions. Use boolean variables (known as flags) for flow control, if necessary.
Always catch the most derived exception class first. That means you should catch InvalidOperationException first, before trying to catch Exception. You need to reverse the order of your catch blocks in the code that you have.
You should practically never catch System.Exception. The only exceptions that you should catch are those that you explicitly understand and are going to be able to handle. There's virtually no way that you're going to know what went wrong or how to handle it when the only information you have is that a generic exception was thrown.
Along those same lines, you also should never throw this exception from your own code. Choose a more descriptive exception class that inherits from the base System.Exception class, or create your own by inheriting from the same.
I see that other answers are showing you sample code of what your code should look like, were it to be rewritten. I'm not going to do that because if I rewrote your code to be correct, I'd end up with this:
class Xxx
{
public Xxx()
{
}
}
Not particularly helpful.
If the code is like this
class xxx
{
public xxx(){
try
{
throw new Exception(InvalidoperationException);
}
catch(InvalidoperationException x)
{
}
catch(Exception x)
{
}
}
}
It should compile and raise your exception and catch. Otherwise your code will not compile at all.
No exception will be thrown as this code will not even compile.
Regardless - several points:
When using exception handling, put the more specific exception before the less specific ones (so the catch of InvalidOperationException should be before the one for Exception).
Catching Exception is normally no very useful.
If you catch an exception, do something with it.
You probably meant:
throw new InvalidOperationException();
However, the way you structured your exceptions, the catch(Exception x) block would have run.
You should write:
class xxx
{
public void Test()
{
try
{
throw new InvalidoperationException();
}
catch(InvalidoperationException exception)
{
// Do smth with exception;
}
catch(Exception exception)
{
throw; // Rethrows your exception;
}
}
}
InvalidOperationException inherits from Exception.
catch tries to processes the most specific branch, so catch (InvalidOperationException x) will be executed here.
Nope. It wouldn't compile. So, it there's no question about as to which exception will be generated.
Your code should be something like this :
class xxx
{
public void Test()
{
try
{
throw new InvalidoperationException();
}
catch(InvalidoperationException exception)
{
// Something about InvalidOperationException;
}
catch(Exception exception)
{
// Something about the Exception
}
}
}
Point to be noted :
Write more specific class of Exception first, hence we write InvalidOperationException prior to Exception class.
Ignoring the compile issue.... the first matching exception block (catch(Exception x)) will get the exception. You then ignore the exception and don't re-throw, so exception will be seen by the outside world. That doesn't make it good practice, though... in particular, catching an arbitrary Exception and ignoring it is risky - it could have been anything... it isn't necessarily the exception you thought it was.
Well, the code won't compile, but I'll just ignore that...
If I'll just look at the line:
throw new Exception(InvalidoperationException);
1st of all, according to MSDN there is no such constructor. So I will assume you meant the constructor: Exception(String msg, Exception innerException). Meaning:
throw new Exception("blabla", InvalidoperationException);
The exception that is being thrown is of type Exception and not InvalidOperationException. So ONLY catch(Exception x) can catch it.
If you would've thrown InvalidoperationException than the way you wrote the order of the catches, the Exception class would get caught first.
The order of the catches does matter.
The best advice I can give you is simply try it yourself and see what happens.