Is there a extended TryCatch-Snippet ?
-
Hi, Does anyone know whether there is a TryCatch-Snippet wich can built try{}catch{}-blocks with all possible Exceptions thrown by a Methode ? or Is there a way to create such a snippet ?
I don't know if such snippets exist but I know that you can create your own snippets
-
Hi, Does anyone know whether there is a TryCatch-Snippet wich can built try{}catch{}-blocks with all possible Exceptions thrown by a Methode ? or Is there a way to create such a snippet ?
There isn't one. How would it be possible for the snippet manager to know all Exceptions possible from a method, especially if the method made calls other methods in an external assembly?
only two letters away from being an asset
-
Hi, Does anyone know whether there is a TryCatch-Snippet wich can built try{}catch{}-blocks with all possible Exceptions thrown by a Methode ? or Is there a way to create such a snippet ?
try
{
}
catch(Exception error)
{
}will catch all exceptions. However, this is not a recommended practice since it will also catch unrecoverable or systems exceptions (e.g. System.OutOfMemoryException, SecurityException, ThreadAbortException, etc.) The best practice is to catch only the exceptions you can recover from. Otherwise, don't handle them.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
try
{
}
catch(Exception error)
{
}will catch all exceptions. However, this is not a recommended practice since it will also catch unrecoverable or systems exceptions (e.g. System.OutOfMemoryException, SecurityException, ThreadAbortException, etc.) The best practice is to catch only the exceptions you can recover from. Otherwise, don't handle them.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Judah Himango wrote:
will catch all exceptions
Well, not all, only .NET exceptions. To catch all exceptions, you have to specify a parameterless catch:
try {
// code
} catch {
// catches any exception
}--- single minded; short sighted; long gone;
Right, it will catch all .NET exceptions. An empty catch will catch non-exception objects -- CLI languages are urged, but not required to, throw only System.Exception objects. However, I wouldn't call those exceptions anymore; those are thrown objects, not thrown exceptions, right?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Judah Himango wrote:
will catch all exceptions
Well, not all, only .NET exceptions. To catch all exceptions, you have to specify a parameterless catch:
try {
// code
} catch {
// catches any exception
}--- single minded; short sighted; long gone;
I read somewhere that this has changed in .NET 2.0 and you don't need empty catch blocks anymore.
Kevin
-
Right, it will catch all .NET exceptions. An empty catch will catch non-exception objects -- CLI languages are urged, but not required to, throw only System.Exception objects. However, I wouldn't call those exceptions anymore; those are thrown objects, not thrown exceptions, right?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
However, I wouldn't call those exceptions anymore; those are thrown objects, not thrown exceptions, right?
I would call an exception an exception, regardless of what object is thrown to handle it. The exception is the situation, not the object.
--- single minded; short sighted; long gone;
-
Judah Himango wrote:
However, I wouldn't call those exceptions anymore; those are thrown objects, not thrown exceptions, right?
I would call an exception an exception, regardless of what object is thrown to handle it. The exception is the situation, not the object.
--- single minded; short sighted; long gone;
Ah, see, when I was talking about exceptions, I was talking about System.Exception-based classes. Anyways, I suppose it's not such a big deal. *edit* after looking into this a bit, I see the framework also refers to non-System.Exception objects which are thrown as "exceptions" in the documentation - interesting! So, you were right. Another interesting side note is the System.Runtime.CompilerServices.RuntimeCompatibilityAttribute which tells the CLR to wrap all non-System.Exception "exceptions" in a real exception class before throwing it.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
I read somewhere that this has changed in .NET 2.0 and you don't need empty catch blocks anymore.
Kevin
There is a System.Runtime.CompilerServices.RuntimeCompatibilityAttribute for assemblies that tells the runtime whether to wrap all "exceptions" that do not derive from System.Exception with a System.Runtime.CompilerServices.RuntimeWrappedException. Maybe that's what you're thinking of?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Master's Decree: It's By My Spirit (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango