- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I'm not sure the statement "But the query definitely should have returned results." is correct when the sql query contains a syntax error...
Admin
I understood it as meaning "the intended query"...
Admin
Result of SQL query could be also an error. You want it returned instead of hiding it quitely.
Admin
The database can alert you to queries that take a long time to execute, but it doesn't know how much time is spent in the network in between the application and database, so the database's number is less helpful when trying to figure out why some specific request to the app took a long time to return results. Having both numbers is ideal, since they're good for different things.
Admin
The log warning is specifically about a "long query". I don't think whoever wrote that even considered such details as network latency.
The entire function smells of lazy convenience wrapper anyway.
Why bother handling errors? Too much repeated work. Let's just not surface them.
"That one time I needed to debug a long query" so let's just bake it into the wrapper forever.
Why bother have 2 functions when one vs multi results can be combined. It's DRY! No but whatever -- I've had seniority code reviewers forcing me to "merge and factorize" functions like that.
It's a helper method, right?
Admin
I like that a query taking over 0.4 seconds is classed as 'long'. They need to come speak with our SQL developers, they've got queries that run for upwards for 30 minutes!
Admin
This is one of my biggest beefs with AI coding. It seems to have a pathological need to avoid failures, so it's always trying to add backwards compatibility and silent fallbacks, even if it means faking a return. I know, there are times when that's appropriate, but when I'm in dev mode I want things to break fast and loud so that we can, y'know, actually find and fix the problems before they reach prod.
Admin
Oof, nasty. "Senior" developers who've never learned about the negative value of control coupling. Yourdon and Constantine must be having fits (or, in Yourdon's case, turning in his grave).
Admin
Catching exceptions is fine. Do not force calling code to handle YOUR exceptions. However always return a technical result, even if it's a bool. Or at least null so the caller can differ between outcomes.
Admin
I'm surprised you only met one person like that! That particular anti-pattern seems to show up a lot on this site.
Admin
Exceptions should be caught at the level they can be acted upon. If we're inside a "do an action in the database" function, that function itself has no idea what the recovery from a failure should be- each caller may want to respond differently. So the exception should get raised to somebody who knows what should happen next.
Admin
Uh, it does kinda, assuming that it transmits its response over a reliable connection (as in https://en.wikipedia.org/wiki/Reliability_%28computer_networking%29). A reliable connections allows the server to time the response receipt confirmation. Afaik, all sane TCP libraries allow blocking until that happens.
What it cannot know is how long the request travelled from client to server. One could, of course, have the client timestamp its request as part of the DBMS protocol and hope that its clock isn't too far off from coordinated time (or that the transmission is subject to the fundamental clock synchronisation issues introduced by special relativity).