Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception context in PSQL exception handlers [CORE1132] #1554

Closed
firebird-issue-importer opened this issue Feb 16, 2007 · 8 comments
Closed

Exception context in PSQL exception handlers [CORE1132] #1554

firebird-issue-importer opened this issue Feb 16, 2007 · 8 comments

Comments

@firebird-issue-importer

Submitted by: StudSW (studsw)

Votes: 6

The possibility to obtain exception text or it's parts (e.g. unique contraint name, FK name, deadlock on what, etc.) increases flexibility of PSQL exception handlers.

It is useful if the procedure returns Error Codes, but no exceptions (expesially if proc cals are nested). Or, let's say, no non-fatal (e.g. contraint filure can be assumed for some cases) exceptions.
This gives unified exception handling for all "user" exceptions/

Also, commonly, to show user-friendly messages some extra queries to DB are required. Having handler on server side - it is more easy to obtain this information (or create a table for with user-messages for all UNIQUE, FOREIGN and so on)

So, the procedure can catch all self-related errors and exceptions, making its interface more exact for callers.

Also the client may stay uninvolved in the server-side processing.

Currently, any proccessing in PSQL that may throw non-user exception (e.g. constraint violation) must break its work and return exception to client-side in order to obtain the needed information about it.
So on, the name of constraint is not user-friendly (or lets say cleint-friendly) and to show a little bit useful information to user it needs to request it from server (from rdb$metadata or from applevel metadata).

So the client must be able to catch and process things which it doesn't need.

I think this improvement is needed to make stored procedures more autonomic without any need of involving client-side in "server-work".

Best regards, StudSW

Commits: ebd0d3c

====== Test Details ======

See functional\exception\handling_name_and_message.fbt

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 20, 2007

Modified by: StudSW (studsw)

priority: Minor [ 4 ] => Major [ 3 ]

Component: Engine [ 10000 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 1, 2007

Modified by: StudSW (studsw)

issuetype: New Feature [ 2 ] => Improvement [ 4 ]

description: The possibility to obtain exception text or it's parts (e.g. unique contraint name, FK name, deadlock on what, etc.) increases flexibility of PSQL exception handlers.

It is useful if the procedure returns Error Codes, but no exceptions (expesially if proc cals are nested). Or, let's say, no non-fatal (e.g. contraint filure can be assumed for some cases) exceptions.
This gives unified exception handling for all "user" exceptions/

Also, commonly, to show user-friendly messages some extra queries to DB are required. Having handler on server side - it is more easy to obtain this information (or create a table for with user-messages for all UNIQUE, FOREIGN and so on)

So, the procedure can catch all self-related errors and exceptions, making its interface more exact for callers.

Best regards, StudSW

=>

The possibility to obtain exception text or it's parts (e.g. unique contraint name, FK name, deadlock on what, etc.) increases flexibility of PSQL exception handlers.

It is useful if the procedure returns Error Codes, but no exceptions (expesially if proc cals are nested). Or, let's say, no non-fatal (e.g. contraint filure can be assumed for some cases) exceptions.
This gives unified exception handling for all "user" exceptions/

Also, commonly, to show user-friendly messages some extra queries to DB are required. Having handler on server side - it is more easy to obtain this information (or create a table for with user-messages for all UNIQUE, FOREIGN and so on)

So, the procedure can catch all self-related errors and exceptions, making its interface more exact for callers.

Also the client may stay uninvolved in the server-side processing.

Currently, any proccessing in PSQL that may throw non-user exception (e.g. constraint violation) must break its work and return exception to client-side in order to obtain the needed information about it.
So on, the name of constraint is not user-friendly (or lets say cleint-friendly) and to show a little bit useful information to user it needs to request it from server (from rdb$metadata or from applevel metadata).

So the client must be able to catch and process things which it doesn't need.

I think this improvement is needed to make stored procedures more autonomic without any need of involving client-side in "server-work".

Best regards, StudSW

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

Workflow: jira [ 11610 ] => Firebird [ 15446 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 9, 2016

Modified by: @pavel-zotov

status: Open [ 1 ] => Open [ 1 ]

QA Status: Covered by another test(s)

Test Details: See functional\exception\handling_name_and_message.fbt

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 9, 2016

Modified by: @pavel-zotov

status: Open [ 1 ] => Closed [ 6 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 9, 2016

Commented by: @pavel-zotov

Ticket will be closed after 'Resolved' flag will be set.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 9, 2016

Modified by: @pavel-zotov

status: Closed [ 6 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 6, 2016

Modified by: @dyemanov

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

assignee: Dmitry Yemanov [ dimitr ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants