Re^4: SQL: Update column(s) value with extra WHERE

Second, I disagree with dieing at any point in my programs and I look down on code which does that and forces me to try/catch/eval each of its calls instead of checking the error code that each function, IMO, should return

I'm familiar with this argument, and I wouldn't bother extending it except that in your own code above you wrote:

# dies on error
sub   db_modify_column_value
[download]

So to some degree, you must see the benefit of not needing to check the return value of db_modify_column_value each time you call it.

For programs in C/C++ where exception handling can get messy and affects the performance (which is the whole reason for using C/C++) there's a decent reason to avoid exceptions and use return codes. There's also a perfect reason for using return codes on actions where failure is common or expected, and where a user will likely have a fall-back plan. But in code for everyday scripting where you expect it to work and the fall-back plan is basically "report the error as well as possible and give up", there's no reason not to use them. Using the ones that DBI provides for you saves you a ton of fingerwork and saves the person reading your code from eye strain.

BTW, you didn't check any return values of 'prepare' or whether iterating 'fetchrow_hashref' ended naturally or with an error (like the connection resetting). If you turn exceptions off, you need to add error checking *everywhere* or else you can end up with some really hard to diagnose bugs later on.

Comment on Re^4: SQL: Update column(s) value with extra WHERE Download Code

Replies are listed 'Best First'.
Re^5: SQL: Update column(s) value with extra WHERE (Real-time Computing and Virtual Machine References) by eyepopslikeamosquito (Archbishop) on Jul 19, 2023 at 09:12 UTC
> For programs in C/C++ where exception handling can get messy and affects the performance (which is the whole reason for using C/C++) there's a decent reason to avoid exceptions and use return codes Nowadays, performance is almost never a reason to avoid exceptions in C++. The only exception (pun intended) I'm aware of is hard real-time applications where people might die if a computation takes too long (in such applications, even `malloc` is banned). > There's also a perfect reason for using return codes on actions where failure is common or expected, and where a user will likely have a fall-back plan Yes. Though more or less a matter of taste, the code can sometimes look simpler and clearer to me when checking for common and expected failure return codes, rather than throwing and catching exceptions. See also: Exceptions and Error Handling (ISO C++) - 'As a rule of thumb, exception handling is extremely cheap when you don't throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, "normal code" is faster than code using error-return codes and tests. You incur cost only when you have an error.' In what ways do c++ exceptions slow down code when there are no exceptions thrown (SO) Does try catch in C++ affect performance when not hit (SO) Real-time Computing References Fault tolerance (wikipedia) Embedded system (wikipedia) Real-time computing (wikipedia) Safety-critical system (wikipedia) Software fault tolerance (wikipedia) RAID (wikipedia) - redundant array of inexpensive/independent disks Cloud storage (wikipedia) - a model of computer data storage in which data, said to be on "the cloud", is stored remotely in logical pools and is accessible to users over a network, typically the Internet Arduino (wikipedia) - designs and manufactures single-board microcontrollers and microcontroller kits for building digital devices Dongle (wikipedia) - a small piece of computer hardware that connects to a port on another device to provide it with additional functionality GPSd - gpsd is a service daemon that monitors one or more GPSes or AIS receivers attached to a host computer through serial or USB ports, making all data on the location/course/velocity of the sensors available to be queried on TCP port 2947 of the host computer GPS::NMEA by Slaven Rezic (CPAN) - Perl interface to GPS equipment using the NMEA Protocol Tutorial for NMEA GPS perlipc (perldoc) alarm (perldoc) Basic Fault Tolerant Software Techniques (geekforgeeks) Virtual Machines References Re^2: Dancer newbie question by NERDVANA (2024) - advises managing your own virtual machine on a cloud platform like Linode or Digital Ocean (notes that DigitalOcean also has the App service which deploys one of your GitHub repos directly into a VM for you) Re: An update (was: Re^2: Holding site variables) by afoken (2024) - advises Bod to consider using virtual machines for the development server; compares VMware, VirtualBox, Proxmox (Debian Linux, provides VMs and containers, open source); RAID, SATA SSDs v SMRs, UPS discussed too	[reply] [d/l]
Re^5: SQL: Update column(s) value with extra WHERE by bliako (Abbot) on Jul 19, 2023 at 07:26 UTC
`except that in your own code above you wrote:` In light of the recent `die` discussions mentioned I did not want to inflame things and divert the focus to `die`. Indeed the focus has shifted and I failed! On the other hand, code like that is far more convenient which is an added point granted in favour of `die`. `BTW, you didn't check any return values of 'prepare' or whether iterating 'fetchrow_hashref' ended naturally or with an error (like the connection resetting).` Good point. Though the above code was just for asking the question which focused elsewhere: `find lib -type f -exec grep -H -w 'prepare(' \{\} \; if( ! defined $sth ){ warn $sqlstr."\n".__FILE__."::db_get_enums_for_t +able() (line ".__LINE__.") : error, call to ".'prepare()'." has faile +d for above SQL: ".$dbh->errstr; return undef } ...` [download]	[reply] [d/l] [select]