Is there a way to catch the cancel button or the interrupt button in a Databricks notebook?

[Jfoxyyc]

I'm running oracledb package and it uses sessions. When you cancel a running query it doesn't close the session even if you have a try catch block because a cancel or interrupt issues a kill command on the process. Is there a method to catch the cancel or interrupt? In an ipynb notebook I could use except KeyboardInterrupt.

[Aviral-Bhardwaj]

Please share a code block by that we can test in our system and provide you correct solution

[Jfoxyyc]

Just find yourself a long running query or create a view that cross joins a quadrillion records (make sure you have the ability to kill this session). Then import oracledb in a notebook, connect to that server, and query that long running query. Proceed to hit cancel in the notebook cell or interrupt in the notebook at the top right. The session doesn't close, you'd need to connection.close(force=True) or pool.close(force=True).

What i'm looking for is a way to catch the 'cancel' button in a cell or the 'interrupt' button in a notebook so I can capture this in a try: except: block and issue the close() command.

[Anonymous]

Hi @Jordan Fox​ 

Hope everything is going great.

Just wanted to check in if you were able to resolve your issue. If yes, would you be happy to mark an answer as best so that other members can find the solution more quickly? If not, please tell us so we can help you. 

Cheers!

[jonathan-dufaul]

I'm having the same issue and this has been frustrating as heck.

[gustavo_woiler]

I was having the same issue and I think I was finally able to solve it!
When you simply except and capture the KeyboardInterrupt signal and do not raise it, the notebook gets into an endless cycle of "interrupting..." and never does anything.
However, if you catch the KeyboardInterrupt exception, do what you want to do, and then raise it, the notebook finishes as expected.
Funny thing is that I couldn't get the exception handling block to print anything to the cell's output...

But I know it was executed because I wrote a file during the exception handling, and it was there after.

Solution below: