Fix schema plugin unreachable except block

[odaysec]

fix is to ensure that more specific exceptions are caught before more general ones, and that there is only one handler for a given exception type in a try statement. In this case, we have two except Exception as e: blocks; the second one (lines 332–334) is unreachable and should be removed. Additionally, the code after the return inside the first except (lines 314–330) is dead and should be restored to the normal execution path inside the try block instead of being inside the exception handler.

The best fix that preserves intended functionality is:

• Keep a single except Exception as e: block at the end of the try.
• Move the schema‑building logic (currently indented under the first except after line 313) back into the try block, following the connection/cursor setup and any other preparatory logic (within the same try that begins around line 237).
• Remove the first except Exception as e: (lines 301–312) entirely in favor of the final except (lines 332–334), or equivalently, merge their logging/return behavior into a single except at the end.
• Ensure that the single except logs the detailed error and either returns a ResultWithMetadata object (as in the first handler) or re‑raises, whichever matches the plugin’s contract; given the surrounding code, returning an error ResultWithMetadata is consistent with other plugin methods that encapsulate errors.

Since we only see part of the try block, the concrete change within application/single_app/semantic_kernel_plugins/sql_schema_plugin.py should:

• Delete the first except Exception as e: block (lines 301–312).
• Dedent the currently unreachable schema retrieval code (lines 314–330) so it is part of the main try block.
• Replace the second except Exception as e: (lines 332–334) with a handler that performs the same logging and ResultWithMetadata return behavior as the original first handler, instead of re‑raising.

[paullizer]

Hey @odaysec , thanks for the contribution. Can you please retarget this PR to branch off Development (instead of opening directly against main)? If you already have commits, you can rebase onto Development or cherry-pick them over.

On the code change: I’m good with consolidating exception handling for better error collection, but the current return path includes str(e) in the response. Exception text can accidentally leak sensitive details (hostnames, DB names, table names, connection info, SQL). Can we sanitize the user-facing error (generic message), and keep the detailed exception only in logs? Also, use debug_print() instead of print, this allows the admin to control which is presented to the console while logs are still saved to app insights via log_event. I am working on writing our contribution framework to make it easier to understand these requests.

I hope you follow-up with a new PR! It's great to have you contributing!