UDF division by 0 [CORE742]

[firebird-automations]

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]

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]

Modified by: @pcisar

issuetype: New Feature \[ 2 \] =\> Improvement \[ 4 \] assignee: Dmitry Yemanov \[ dimitr \] SF\_ID: 1388205 =\>

[firebird-automations]

Modified by: @pcisar

assignee: Dmitry Yemanov \[ dimitr \] =\>

[firebird-automations]

Modified by: @pcisar

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

[firebird-automations]

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]

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]

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]

Commented by: @asfernandes

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

[firebird-automations]

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]

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]

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]

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