|
Most of the certifications I had to take were worthless rote BS. Had to memorize the properties of different optical cables. They're so expensive that you'd never just order them without making sure they were the right kind.
Minor point- Egyptian pyramids were not built by slaves. They were built by corvee labor, drafted during the flood season of the Nile. Equivalent to a tax in a non-monetary economy. They did massive cattle drives from the Delta and fed the workers far more beef than they would ever have seen in their lives. They were also paid in beer.
|
|
|
|
|
"In a stunning announcement today, a plug-in for the ChatGPT AI was released. If you have access to a 3D printer and the raw materials, you can now have the AI create for you your own children. You can select from a board range of physical and mental characteristics for your child: gender (or lack thereof), ethnicity, demeanor, intelligence, and so on. The crowd was shocked when the presenter from the plug-in company jumped into the 3D printer's material hopper, and was then reconstituted as his own child. After a few moments of confusion (an issue to be corrected in version 1.1 according to company officials) the child continued the presentation."
Software Zen: delete this;
|
|
|
|
|
They used to grind us down with pages of sums because they needed us to be calculating machines. Now they grind us down with bullshit because they need bullshitters. Now that AI really is a master of bullshit, they should leave us to be human beings.
|
|
|
|
|
Well, it's a glorified search engine with a fancy language output algorithm. But people are easily-pleased... it's interesting that it (apparently) passed the Turing test recently: it is possible, of course, to point out that the Turing test can equally as well be applied to the person administering it as to the machine being tested... that ChatGPT passed says more about the current educational level of the species than it does about the AI itself.
|
|
|
|
|
|
|
As I am getting older I am learning that we took away too much "automatism" from our life and it is not a good thing since now we are getting negative returns.
For example:
- we don't walk or do any physical activity, why should we when everything is so much easier with car, or with elevator to go to 3rd floor, or with electric chainsaw when you just need to cut through one inch thick branch... you get the point... and eventually our body and brain suffers (just started to run few years ago to try to counter this and I'm still impressed with overall gains I get back)
- we don't think deep, why should we when everything is available on Google (and via ChatGPT now). So we slowly loose our imagination since we don't have a need to use it
- we don't talk to people face to face, it's easier to automate this by using chats and all other sort of modern tools
I do like ChatGPT, it's easiest way to get answer to some fairly complex questions BUT you must validate it like any other answer you get instead of following it blindly (so it is not ChatGPT's problem)
ChatGPT will become even better, and that's not a bad thing, but we should treat it as we should treat cars - and not use it for every elephant thing, we still must try to think for the sake of thinking
However... people are lazy, kids are even more "lazier" (they are very good at finding the path that consume the least energy, have two of them... oh boy...) and I am really afraid of what ChatGPT and similar tech will to them because of reasons listed above.
|
|
|
|
|
Mirko796 wrote: we don't walk or do any physical activity
You mean like working 16 hours a day for 6 days a week bent over in a field to bring in the crops? No thanks.
Mirko796 wrote: we don't think deep,
Sorry but I have no idea what that comment means. More people can express themselves now and can do so using a vast number of ways to do it.
Mirko796 wrote: we don't talk to people face to face,
So?
When I was in school and a friend's parent moved them to another city that person was gone forever. Long distance charges and the availability of only one phone in each household guaranteed that. Not to mention that moving meant the phone number changed.
Yet now young people can maintain friendships from a young age with someone they have not seen for years. And they can make friends with people that they have never even met in person. And arrange to meet them again or for the first time when they are old enough to travel.
Of course in the good ol' days your friend might be trundled off in a wagon never to be seen or heard from again because they were killed on the way to a different town or country as they were attempting to escape the plague, war, famine or repressive regime.
|
|
|
|
|
Weapons of Mass Instruction
Read it
|
|
|
|
|
I am tired of tutorials and senior programmers which "explain" that exceptions should never be handled in lower level code.
Here is my example to end all examples why you do need to catch exceptions sometimes in low level code:
We have a component for importing millions of records of data from a delimited text file, process it and store it in cleaned-up form in a database.
Now, data in delimited text files is "quite" clean but very occasionally it is not, and we want the import to stop and indicate WHICH column. So we can fix the import data, or the thing which generates it.
Let's say that's a date column and we have Convert.ToDateTime() and there are 10 date columns in that structure - it will throw an exception allright which bubbles up but will be the unhelpful
String '184' was not recognized as a valid DateTime .
So - catch the exception, add row and column info and then re-throw. Really, anyone who sees this as wrong must be working with mickey-mouse applications where you never have to sift through millions of records to find the one datum which is wrong. Isn't it?
Out of this "purity" of exception handling we get abominations like the SQL Server error message "String or binary data would be truncated." (I know it's finally handled as of SQL Server 2019, but it's been around for decades.)
|
|
|
|
|
Depends what the source of the bad date was: if it's the user, then I'd be processing that at the point where he said "Enter" so lower level code never meets the problem - and I'd be using DateTIme.TryParse or TryParseExact instead anyway so the exception would never occur.
Personally, I handle errors as close to the "source" as feasible - provided I can handle it. If it's an error where it makes sense to handle it, do: your error message is indeed unhelpful, so I'd wrap it as an inner exception with a "The database was not updated because ..." message and throw that to give relevant info to higher code. If "this code" can't handle it, then let a higher level do it - but give them info to help them much as you are.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
nepdev wrote: catch the exception, add row and column info and then re-throw.
So really, you are not actually "handling" the exception in the lower level code, you are in fact repackaging it and letting the higher level code deal with it. I think the definition of "handled" would usually be that it is dealt with and the higher level code never knows about it.
Now, if your example was, we "handle" the exception at the lower level by logging it and let the processing continue, that might be a wee bit better. 
|
|
|
|
|
Yes, adding detail and rethrowing is not "handling".
|
|
|
|
|
Adding detail *is* important at the lower level exception. Even if it can't be "fixed" at the lower level, at least provide the detail to indicate where the error really is. I've seen so many cases where staff has to stop and sift through files or tables to get to the one record that caused the problem. Staff work is expensive. If the some key data is logged (or rethrown) and the program can move on, then it will save plenty of time.
I think he's complaining that people/tutorials advocate for simply coding a "No Can Do" exception message with no context about where to find the problem.
|
|
|
|
|
Peter Kelley 2021 wrote: Adding detail *is* important at the lower level exception
However the point in the previous point is not about that.
It is about that wrapping it and then throwing it again is not handling it - as it said.
|
|
|
|
|
I agree. When doing what seems to me some sort of batch processing, log the error and location then carry on.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I agree.
No method knows how deep it is going to be.
Catch an Exception, add detail, and rethrow as necessary if you can't handle it.
Additionally, don't try to validate every value if you're just going to pass it on to another method anyway. Having a whole stack of methods checking and re-checking a value is a waste of time.
|
|
|
|
|
I feel a contradiction between your first and third lines. Checking input is a requirement in my workplace (financials). I think everybody here more than once burned itself when said procedure got called from other procedure than the original caller procedure in the design.
Which leads to the "do one thing" theory - was it dissected into a chain of procedures just to reach purity? Aesthetics?
|
|
|
|
|
nepdev wrote: I am tired of tutorials and senior programmers which "explain" that exceptions should never be handled in lower level code.
Your sources are flawed.
nepdev wrote: So - catch the exception, add row and column info and then re-throw
However that example would certainly not seem like a good way to prove your point.
Especially since you are said "millions" of rows and that you know that you expect some of the data to be flawed.
It would seem to me that you would want to continue. So you report the bad row and then continue. No exception should be thrown.
As well you might even to decide to attempt to clean some bad data. Especially after looking at the prior reported problems.
|
|
|
|
|
Exception handling is an alternative to solving the source of the problem or finding an alternative solution.
For example, "cleaning" data at the source and adding to a suspense file is usually preferable to throwing exceptions in the back end.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
nepdev wrote: importing millions of records of data from a delimited text file,
You are dealing with a doomed data format: even if you have complete control over creating, and managing, the deli8mited text file.
The question of when, where, to handle errors in this case is like asking if a pig would look better with lipstick before, or after, if flies.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
oh, sure front end says they have a date check
except their date check does not include sanity check
so might go through fine till hits server which say, uhm, this is 01/01/1803, and I am setup to only allow values above last year, so error - "invalid date"
|
|
|
|
|
No
This is why we have DateTime.TryParse. Exceptions are expensive to throw and catch because they have to stop and construct a stack trace. You most definitely should not just "catch the exception ... and then re-throw" if this is a common enough occurrence. On the other hand, if you don't know for sure that this is a possible outcome and the date-time parsing is not under your control, I totally understand catching & re-throwing with more context. But if you're the one doing DateTime.Parse willy-nilly on a string, YATA.
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|
It also depends on the size of your transaction.
If all million rows must commit as one transaction, then you should let the exception bubble up to the level controlling the transaction.
Same if the scope of the transaction is at the row level. Skip the transaction for this row, log/capture for replay and move to the next.
|
|
|
|
|
Yes, in situations where clear, concise information about success and failure is important, capture errors at a lower level. I like to accumulate them, not stopping at error, but storing just enough information to give a complete analysis at the end, but also assessing the weight of errors as I go to just give up when they are too many to continue. Within the report of successes and failures, I supply an option to undo the storage of the data in case they want to fix their data and then try again cleanly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
