|
that is perfectly legal. The outer try-catch will catch whatever gets thrown outside the inner try block, e.g. an exception occurring in the inner finally block.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
this will hide the inner exception of the inner try?
Help people,so poeple can help you.
|
|
|
|
|
Well, if you don't use an inner catch, every exception in both the inner and outer try block, will be caught by the outer catch block.
|
|
|
|
|
the finally block is always executed, and any exception that gets thrown will be caught by the first surrounding and matching catch block. So the finally block will execute first (unless the catch belongs to the same try as the finally).
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
A catch block containing nothing but a rethrow is by definition pointless. That is,
try {
doStuff();
} catch {
throw;
}
... is equivalent to simply calling doStuff(). So, if you haven't simplified out some code from the catch block, the outer try is pointless.
However, in the general case, this type of construct can be useful, because of the order of operations. In your example, if an exception is thrown, code is executed in the order inner-try, finally, catch, which means that the exception handler is called after the finally has been called and cleaned up. In a standard try { ... } catch { ... } finally { ... }, the order is try, catch, finally, so exception handlers are called before cleanup. If your exception handler is logging, aborting execution or calling something which assumes that the data is in a good state, the former can be better.
Edit: also, Luc makes a good point, if the finally code throws an exception, this structure will catch it, though finally code should not throw exceptions unless it is truly unavoidable.
|
|
|
|
|
The outer try/catch in this example is pointless, remove it.
If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally.
Nested try/catches (while sometimes necessary) are a code smell and should be investigated thoroughly. (Or Thoreau[^]ly -- simplify simplify.)
|
|
|
|
|
PIEBALDconsult wrote: If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally.
If the catch in the outer try/catch actually does something, then your suggestion would change what happens to exceptions thrown by the finally block itself.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: exceptions thrown by the finally block itself.
Of which there are none. or put a try/catch in the finally.
|
|
|
|
|
PIEBALDconsult wrote: Of which there are none
Of course there are, that is exactly what the three dots are standing for. You can't escape nested try constructs if it has to be fool proof...
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: You can't escape nested try constructs
Sure I can, I'll write a method. And I did say that some times they're necessary. However, taking the least scope route, if you want to protect against Exceptions in a finally (and you shouldn't need too), then put the try/catch there.
|
|
|
|
|
Pointless with regards to how the code executes, but not pointless if you are debugging. The outer catch block gives you a place to put a breakpoint so you can see when exceptions occur. I expect that is the reason for it. But the outer try-catch block can be safely removed for production code.
|
|
|
|
|
Then put a catch on the try/finally.
|
|
|
|
|
Except if the exception occurs during execution of the finally-block...
|
|
|
|
|
My memory may not be correct, but I seem to recall a time in C++ when try-finally was a macro and try-catch a language intrinsic, so you couldn't mix them together. If you wanted to do both, you pretty much had to code it up that way. Maybe I recall wrong though?
Unless there's more code inside the try-catch that isn't inside the try-finally, it doesn't make much sense to code it that way.
patbob
|
|
|
|
|
It is legal but personally,
I prefer
try
{
}
catch (IOException e)
{
}
catch(MyException e)
{
}
.
.
.
.
.
.
catch (Exception e){
}
|
|
|
|
|
That's a do-while.
|
|
|
|
|
How to load Data From SQL databse
|
|
|
|
|
|
|
Hi!
I am making Linqtosql application in which classes are used in mapping of database.
I want to let the user input the class name from interface(windows form)
for e.g
if
Class name = hello
its object declaration is
e.g
hello object = new hello()
now in this I want the user to enter the class name "hello"
i tried storing user input in a string , but doesnt work , what to do?
|
|
|
|
|
Use reflections in C# with reflections u can store the class name in a string and then create the object of that class at run time Click Here
modified on Wednesday, May 4, 2011 1:48 AM
|
|
|
|
|
I couldn't understand the tutorial..
plz just in simple explanation , tell that how can i store a class name in string format?
I have a class let say ABC
let say it has fields.
class abc
{
int a;
int b;
}
now if i want to make an object of abc in an another class, through user entering the class name , how to do using reflections?
I am sure it is just 2 lines of code
|
|
|
|
|
Type type = Type.GetType("abc");
object obj = Activator.CreateInstance(type);
pass the class name in the GetType function if the class has a namespace pass it with the namespace.classname
rate me if this post was helpful
modified on Monday, May 9, 2011 6:51 AM
|
|
|
|
|
i tried it.
I had the namespace FYP_RFID and class name RECORDS.
Type type = Type.GetType("FYP_RFID.RECORDS");
object obj = Activator.CreateInstance(type);
BUT when i try to acces any member uding obj.
nothing happens
but when i manually make the object like
RECORDS OBJ = NEW RECORDS();
THEN through obj. function i can acess the members of class. what could be the problem?
(I appreciate you helping me out )
|
|
|
|
|
There is a class called MethodInfo where in you will get all the info of the methods in the object and i would suggest you to learn this from any forums because it would help you more to learn about it like we could only guide you how to do a particular thing it would be good for you to learn new things
|
|
|
|