Issue Details (XML | Word | Printable)

Key: CORE-742
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Michael Trowe
Votes: 1
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

UDF division by 0

Created: 22/Dec/05 12:00 AM   Updated: 25/Mar/15 02:08 PM
Component/s: UDF
Affects Version/s: None
Fix Version/s: None

SF_ID: 1388205

 Description  « Hide
SFID: 1388205#
Submitted By: bubble76

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

Firebird2 Beta1 / Superserver as Service

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:42 AM
Date: 2006-01-03 08:49
Sender: dimitr
Logged In: YES

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

Karol Bieniaszewski added a comment - 23/May/14 06:12 AM
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)

Dmitry Yemanov added a comment - 23/May/14 06:52 AM
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.

Karol Bieniaszewski added a comment - 23/May/14 09:18 PM
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

Adriano dos Santos Fernandes added a comment - 24/May/14 04:13 AM
Karol, do you understand that each language, compiler and OS may implements exceptions in its own unique way?

Karol Bieniaszewski added a comment - 27/May/14 12:20 PM

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

Dmitry Yemanov added a comment - 28/May/14 10:22 AM
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.

Karol Bieniaszewski added a comment - 29/May/14 10:18 AM
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

Karol Bieniaszewski added a comment - 25/Mar/15 02:08 PM
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

 do something
  1/0 // <---- re-raise error as division by zero
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