So I've been assigned to teach a block on exception handling, and I've run into a question I don't have an answer for.  What valid (e.g., don't result in either a compiler, or a run-time, error) commands in Java will keep a finally-block from executing?  A return statement won't do it, but a System.exit(0) statement will.  My understanding is that a finally-block would execute no matter what.  What (valid) statements will prevent a finally-block from doing so, and why?
3961
Considering this code, can I be absolutely sure that the finally block always executes, no matter what something() is?  try {       something();       return success;   }   catch (Exception e) {        return failure;   }   finally {       System.out.println("I don't know if this will get printed out"); }
58461
Consider the code:  PreparedStatement ps = null; ResultSet rs = null; try {   ps = conn.createStatement(myQueryString);   rs = ps.executeQuery();   // process the results... } catch (java.sql.SQLException e) {   log.error("an error!", e);   throw new MyAppException("I'm sorry. Your query did not work."); } finally {   ps.close();   rs.close(); }   The above does not compile, because both PreparedStatement.close() and ResultSet.close() throw a java.sql.SQLException.  So do I add a try/catch block to the finally clause?  Or move the close statements into the try clause?  Or just not bother calling close?
15847
When I debug a C# program and I get an exception throwed (either thrown by code OR thrown by the framework), the IDE stops and get me to the corresponding line in my code.  Everything is fine for now.  I then press "F5" to continue. From this moment, it seams like I'm in an infinite loop. The IDE always get me back to the exception line. I have to Shift + F5 (stop debugging/terminate the program) to get out of his.  I talked with some co-workers here and they told me that this happens sometime to them too.  What's happening?
75794
I've got a bunch of properties which I am going to use read/write locks on. I can implement them either with a try finally or a using clause.  In the try finally I would acquire the lock before the try, and release in the finally. In the using clause, I would create a class which acquires the lock in its constructor, and releases in its Dispose method.  I'm using read/write locks in a lot of places, so I've been looking for ways that might be more concise than try finally. I'm interested in hearing some ideas on why one way may not be recommended, or why one might be better than another.  Method 1 (try finally):  static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock(); private DateTime dtMyDateTime_m public DateTime MyDateTime {     get     {         rwlMyLock_m .AcquireReaderLock(0);         try         {             return dtMyDateTime_m         }         finally         {             rwlMyLock_m .ReleaseReaderLock();         }     }     set     {         rwlMyLock_m .AcquireWriterLock(0);         try         {             dtMyDateTime_m = value;         }         finally         {             rwlMyLock_m .ReleaseWriterLock();         }     } }   Method 2:  static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock(); private DateTime dtMyDateTime_m public DateTime MyDateTime {     get     {         using (new ReadLock(rwlMyLock_m))         {             return dtMyDateTime_m;         }     }     set     {         using (new WriteLock(rwlMyLock_m))         {             dtMyDateTime_m = value;         }     } }  public class ReadLock : IDisposable {     private ReaderWriterLock rwl;     public ReadLock(ReaderWriterLock rwl)     {         this.rwl = rwl;         rwl.AcquireReaderLock(0);     }      public void Dispose()     {         rwl.ReleaseReaderLock();     } }  public class WriteLock : IDisposable {     private ReaderWriterLock rwl;     public WriteLock(ReaderWriterLock rwl)     {         this.rwl = rwl;         rwl.AcquireWriterLock(0);     }      public void Dispose()     {         rwl.ReleaseWriterLock();     } }
98177
In Java, is there an elegant way to detect if an exception occurred prior to running the finally block? When dealing with "close()" statements, it's common to need exception handling within the finally block. Ideally, we'd want to maintain both exceptions and propagate them up (as both of them may contain useful information). The only way I can think of to do this is to have a variable outside the try-catch-finally scope to save a reference to a thrown exception. Then propagate the "saved" exception up with any that occur in the finally block.  Is there a more elegant way of doing this? Perhaps an API call that will reveal this?  Here's some rough code of what I'm talking about:  Throwable t = null;  try {       stream.write(buffer);  } catch(IOException e) {     t = e;   //Need to save this exception for finally     throw e; } finally {        try {        stream.close();   //may throw exception    } catch(IOException e) {       //Is there something better than saving the exception from the exception block?       if(t!=null) {          //propagate the read exception as the "cause"--not great, but you see what I mean.          throw new IOException("Could not close in finally block: " + e.getMessage(),t);       } else {          throw e;  //just pass it up       }        }//end close }   Obviously, there are a number of other similar kludges that might involve saving the exception as an member variable, returning it from a method, etc... but I'm looking for something a bit more elegant.  Maybe something like Thread.getPendingException() or something similar? For that matter, is there an elegant solution in other languages?  This question actually spawned from comments in  that raised an interesting question.
56244
I have a method that I would like to call.  However, I'm looking for a clean, simple way to kill it or force it to return if it is taking too long to execute.  I'm using Java.  to illustrate:  logger.info("sequentially executing all batches..."); for (TestExecutor executor : builder.getExecutors()) { logger.info("executing batch..."); executor.execute(); }   I figure the TestExecutor class should implement Callable and continue in that direction.  But all i want to be able to do is stop executor.execute() if it's taking too long.  Suggestions...?  EDIT  Many of the suggestions received assume that the method being executed that takes a long time contains some kind of loop and that a variable could periodically be checked. However, this is not the case.  So something that won't necessarily be clean and that will just stop the execution whereever it is is acceptable.
44134
Is there a setting in Resharper 4 (or even Visual Studio itself...) that forces a warning if I forget to wrap code in a using block, or ommit the proper Dispose call in a finally block?
29493
I'm in the process of writing a piece of code that connects to a server spawns a bunch of threads using that connection and does a bunch of "stuff".  There are certain instances where the connection fails and I need to stop everything and start from scratch with a new object.  I wanted to clean up after the object but calling thread.stop on the threads, but this method is seemingly deprecated.  What is the recommended alternative to doing this? Should I write my own cleanup and exit method for each of the threads? Set the thread to null? or something else?
24776
I need to spawn a child process that is a console application, and capture its output.  I wrote up the following code for a method:  string retMessage = String.Empty; ProcessStartInfo startInfo = new ProcessStartInfo(); Process p = new Process();  startInfo.CreateNoWindow = true; startInfo.RedirectStandardOutput = true; startInfo.RedirectStandardInput = true;  startInfo.UseShellExecute = false; startInfo.Arguments = command; startInfo.FileName = exec;  p.StartInfo = startInfo; p.Start();  p.OutputDataReceived += new DataReceivedEventHandler (     delegate(object sender, DataReceivedEventArgs e)     {         using (StreamReader output = p.StandardOutput)         {             retMessage = output.ReadToEnd();         }     } );  p.WaitForExit();  return retMessage;   However, this does not return anything. I don't believe the OutputDataReceived event is being called back, or the WaitForExit() command may be blocking the thread so it will never callback.  Any advice?  EDIT: Looks like I was trying too hard with the callback. Doing:  return p.StandardOutput.ReadToEnd();    Appears to work fine.
76588
Possible Duplicate:         If there is a list immediately followed by a code block the code block is not recognized as code (Even though there is a newline between the two).  int answer = 42;  Note: This happens both in the WMD preview and in the final (server rendered) post.
92098
When a java based application starts to misbehave on a windows machine, you want to be able to kill the process in the task manager if you can't quit the application normally. Most of the time, there's more than one java based application running on my machine. Is there a better way than just randomly killing java.exe processes in hope that you'll hit the correct application eventually?  EDIT: Thank you to all the people who pointed me to Sysinternal's Process Explorer - Exactly what I'm looking for!
16499
If yes, on which operating system, shell or whatever?  Consider the following java program (I'm using java just as an example, any language would be good for this question, which is more about operation systems):  public class ExitCode {     public static void main(String args[]) {         System.exit(Integer.parseInt(args[0]));     } }   Running it on Linux and bash, it returns always values less equal 255, e.g. (echo $? prints the exit code of the previous executed command)  &gt; java ExitCode 2; echo $? 2  &gt; java ExitCode 128; echo $? 128  &gt; java ExitCode 255; echo $? 255  &gt; java ExitCode 256; echo $? 0  &gt; java ExitCode 65536; echo $? 0     EDITED: the (only, so far) answer below fully  explain what happens on UNIXes. I'm still wondering about other OSes.
33203
What exception should I throw if I encounter an illegal state - for instance, an initialization method that should only be called once being called a second time?  I don't really see any built-in exception that makes sense.  This seems like something that should be in the framework - am I not poking in the right spot?
43400
So far I've been using public void run() {} methods to execute my code in Java. When/why might one want to use main() or init() instead of run()?
69852
So I came across some code this morning that looked like this:  try {     x = SomeThingDangerous();     return x; } catch (Exception ex) {     throw new DangerousException(ex); } finally {     CleanUpDangerousStuff(); }   Now this code compiles fine and works as it should, but it just doesn't feel right to return from within a try block, especially if there's an associated finally.  My main issue is what happens if the finally throws an exception of it's own? You've got a returned variable but also an exception to deal with... so I'm interested to know what others think about returning from within a try block?
100125
The following method does not compile. Visual Studio warns "An out parameter may not be used within an anonymous method". The WithReaderLock(Proc action) method takes a delegate void Proc().  public Boolean TryGetValue(TKey key, out TValue value) {     Boolean got = false;     WithReaderLock(delegate     {         got = dictionary.TryGetValue(key, out value);     });     return got; }   What's the best way to get this behavior? (Please refrain from providing advice on threadsafe dictionaries, this question is intended to solve the out parameter problem in general).
77222
I have a really simple Java class that effectively decorates a Map with input validation, with the obvious void set() and String get() methods.  I'd like to be able to effectively call those methods and handle return values and exceptions from outside the JVM, but still on the same machine Update: the caller I have in mind is not another JVM; thanks @Dave Ray  My implementation considerations are typical    performance ease of implementation and maintenance (simplicity?) reliability flexibility (i.e. can I call from a remote machine, etc.)   Is there a 'right way?' If not, what are my options, and what are the pro/cons for each?  (Stuff people have actually done and can provide real-life feedback on would be great!)