Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!weretis.net!feeder8.news.weretis.net!usenet.goja.nl.eu.org!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Thu, 10 Jul 2025 20:23:08 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: VMS x86-64 database server
Newsgroups: comp.os.vms
References: <104ejo8$2cobv$1@dont-email.me>
 <686af3b4$0$686$14726298@news.sunsite.dk> <104f0a6$2gn2r$5@dont-email.me>
 <104f2ic$2h75q$2@dont-email.me> <104fc66$2n4ir$2@dont-email.me>
 <104h2d1$31cae$2@dont-email.me> <104hgeh$3474l$11@dont-email.me>
 <104hl76$3595d$2@dont-email.me> <104hojt$360c1$1@dont-email.me>
 <686d12d9$0$694$14726298@news.sunsite.dk> <104k487$3p7d8$8@dont-email.me>
 <104k6p0$3pmuk$1@dont-email.me> <104ka6h$3qkfr$5@dont-email.me>
 <104ki4c$3r3fl$1@dont-email.me> <104l5i4$4bv9$2@dont-email.me>
 <686ec41e$0$686$14726298@news.sunsite.dk> <104msna$fd02$9@dont-email.me>
 <686f0082$0$686$14726298@news.sunsite.dk> <104n4jb$gs8r$2@dont-email.me>
 <686f2472$0$686$14726298@news.sunsite.dk> <104nfgt$mfqt$1@dont-email.me>
 <68704746$0$690$14726298@news.sunsite.dk> <104pk28$14565$3@dont-email.me>
 <104pksf$13i9u$3@dont-email.me> <104plb1$14565$4@dont-email.me>
Content-Language: en-US
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
In-Reply-To: <104plb1$14565$4@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 45
Message-ID: <6870596c$0$690$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 0cb9c9ef.news.sunsite.dk
X-Trace: 1752193389 news.sunsite.dk 690 arne@vajhoej.dk/70.172.216.99:51349
X-Complaints-To: staff@sunsite.dk

On 7/10/2025 8:19 PM, Lawrence D'Oliveiro wrote:
> On Thu, 10 Jul 2025 20:11:59 -0400, Arne Vajhøj wrote:
>> On 7/10/2025 7:58 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 10 Jul 2025 19:05:42 -0400, Arne Vajhøj wrote:
>>>> If the PHP developer configure the database connection to not
>>>> throw exceptions because the developer want to check return
>>>> status, then that must be respected.
>>>
>>> That’s a dumb way of doing it. Most of the errors from an SQL call
>>> indicate program bugs. The only exception I have come across is
>>> IntegrityError, when used to indicate an attempt to add a record
>>> with a duplicate value for a key that must be unique. That can
>>> sometimes be usefully caught and reported back to the user as an
>>> error with the data that they are trying to enter.
>>
>> There are other:
>> * dynamic SQL without prepare/parameters and a bad value
>> * foreign key constraint violation
>> * invalid data value
>> * transaction rollback due to timeout or deadlock
>> * timeout waiting for connection due to connection pool at max
>> * timeout waiting for connection due to connection at max in database
>> * no connectivity to server
>> * invalid login credentials
> 
> Again, all of that can be returned via exceptions, which I can
> selectively catch as appropriate if they’re relevant to my program
> logic, or leave them to be reported as program bugs if I’m not
> expecting them.

Yes.

And in some languages & database technologies you will always
get an exception. Example: Java.

In other languages you will never get an exception because
the language does not support exceptions. Example: C. They have
to use return status.

And in PHP (at least for the most common database extensions)
the developer have the choice - do they want exceptions or do
they want to test on the return status. Everybody should be happy.

Arne