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

UDF division by 0 [CORE742] #1117

Open
firebird-automations opened this issue Dec 22, 2005 · 12 comments
Open

UDF division by 0 [CORE742] #1117

firebird-automations opened this issue Dec 22, 2005 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Michael Trowe (bubble76)

Votes: 1

SFID: 1388205#⁠
Submitted By: bubble76

If in an UDF raises an Exception due to a devision by 0
the Service stops.

WinXP
Firebird2 Beta1 / Superserver as Service

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2006-01-03 08:49
Sender: dimitr
Logged In: YES
user_id=61270

I'm inclined to make it a feature request (convert
arithmetical async exceptions thrown by UDFs to GDS errors).

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 1388205 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10766 ] => Firebird [ 15170 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

I know that this is not the place for discussion - but this is very old report

but please fix this and other udf related errors
this is unacceptable that engine crash because udf raise error
e.g if you have function and you pass regular expression to it and engine crash when expression is not valid? this is wrong at all.

as above 1/0
any other exceptions inside udf should be catched and re-raised as new e.g. GDS_UDF_EXCEPTION or something like that
we do not need any other info (will be good to have original error message from udf but i suppose that this is not so simple)

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Karol, libraries should never throw exceptions to the caller process, this is what software developers should learn from the very beginning. If you need to report an error, return some code in a status variable / result value. Perhaps we could handle some async exceptions (CPU/FPU ones), but definitely not user-defined exceptions.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

Dmitry,
think about udf as internal function
did you see crash when you make e.g. cast('aaa' as integer) no - then why do you think that udf should crash server and corrupt database?

consider another example
udf_a_div_b it should return one value
what value should it return when error occure?

consider update set field=udf

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Karol, do you understand that each language, compiler and OS may implements exceptions in its own unique way?

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

Yes,

but this exception can be catched by code which call dll function
we do not need to provide custom error information
only engine should catch all unhandled by udf excption to one gds_error code

i do not say that if someone raise exception XXX, YYY, ZZZ then engine should reraise it as GDS_XXX, GDS_YYY, GDS_ZZZ
Engine should reraise it as 1 kind exception GDS_UDF

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

The "code which call DLL function" is named Firebird and written in C++ w/ MSVC, this means that its catch block is unlikely to see exceptions passed from UDF written in a different environment.

We can handle hardware exceptions (oveflows, division by zero, etc) and rethrow them as GDS errors, but I still think we shouldn't be over-smart trying to handle software exceptions. UDFs that ignore conventions for dynamic libraries by throwing user-defined exceptions deserve a crash, same as with any other piece of software.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

this is not "over-smart"
this increase Firebird quality

If UDF raise exception because user action unforeseen by the programmer at design/implementation time
then crashing engine and all other connections(SuperServer) to all databases is wrong at all.

Handling hardware exceptions is also good as increase clarify what kind of problem occur - but if this was software exception then FB should raport single "GDS_UDF" error without any other info

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

I think about that and
if engine can handle hardware exceptions like division by zero
this is enough to handle by udf developer any king of errors

consider body of udf

try
do something
except
1/0 // <---- re-raise error as division by zero
end;
yes i know this is not the best solution - but better then crashing server
and user know that something with that function go wrong

e.g if you wrote udf and parameter is regular expression
you never know if user provide acceptable regex syntax
udf raise error as division by 0 and you know that parameter was wrong

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

1 participant