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

Component: Engine [ 10000 ]

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

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

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

QA Status: Covered by another test(s)

Test Details: See functional\exception\handling_name_and_message.fbt

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

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

resolution: Fixed [ 1 ] =>

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

resolution: Fixed [ 1 ]

assignee: Dmitry Yemanov [ dimitr ]