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-automations opened this issue Feb 16, 2007 · 8 comments
Closed

Exception context in PSQL exception handlers [CORE1132] #1554

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

Comments

@firebird-automations
Copy link
Collaborator

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-automations
Copy link
Collaborator Author

Modified by: StudSW (studsw)

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

Component: Engine [ 10000 ]

@firebird-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

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-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

resolution: Fixed [ 1 ] =>

@firebird-automations
Copy link
Collaborator Author

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
Development

No branches or pull requests

2 participants