|
Pls gimme codez, it's urgnt
Who wonders?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Salary cut draws employee ire; management calls it a 'co-investment in training'. That's... an interesting way to fund the training budget
|
|
|
|
|
Very interesting... let's hope it won't become popular, too.
|
|
|
|
|
Is anyone else refreshing Cringely[^] waiting to see how he tears into this stupidity?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Well, at least things like this make it easier for me to figure out which companies I don't want to work for, should I need to start looking. 
|
|
|
|
|
I will only co-invest if I get co-profit.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Every professional C++ engineer sooner or later asks herself a question: “How do I write exception safe code?” The problem is far from trivial. Write in Python instead?
|
|
|
|
|
|
The one thing consistently not mentioned in that article is that the reason exceptions were introduced was because programmers were sloppy about checking error codes.
Their example illustrated this well:
try {
AccessDatabase accessDb = new AccessDatabase();
accessDb.GenerateDatabase();
} catch (Exception e) {
}
public void GenerateDatabase()
{
CreatePhysicalDatabase();
CreateTables();
CreateIndexes();
}
Too often in C code, the error codes that CreatePhysicalDatabase, CreateTables and CreateIndexes returned are just ignored. With exceptions, at least you'll know earlier.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
C code without error checking is dead. Passing this to exceptions is even more deadlier, since introduces also internal changes, as in the example you offered - what is the status of db? created physical; tables; indexes; something else?
Doing this in C is trivial:
struct db* db = NULL;
enum error_step_t e = none;
do {
e = step_create_physical_database;
rv = create_physical_database(&db);
if(rv != 0) {
break;
}
e = step_create_tables;
rv = create_tables(&db);
if(rv != 0) {
break;
}
e = step_create_indexes;
rv = create_indexes(db);
if(rv != 0) {
break;
}
e = none;
} while(0);
|
|
|
|
|
The fact is though, a hell of a lot of programmers simply skipped those checks.
With exceptions, at least the check can't be skipped. Its still not ideal, but generally an uncaught exception is preferrable to an ignored one.
With RAII, the individual steps get unwound, and the programmer is not responsible for tracking (as your error_step_t does) how far along the computation progressed. Admittedly, not all programmers bother with RAII correctly, but at least the program does not continue as if everything was hunky dory.
In this case, I'd have create_physical_database() et al return an object that, during exception unwinding, undoes the steps taken so far.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: generally an uncaught exception is preferrable to an ignored one.
At least they are easier to find when you have to fix legacy code.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's exactly what I meant - an uncaught exception will generally be quite visible. With an unchecked error code the app will carry on oblivious.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Security researchers hack Canon printer firmware to run the classic 90s video game Doom as well as to wreak havoc with other manipulations. On the other hand: good news for Doom fans
|
|
|
|
|
The project aims to improve how open source software is developed and consumed. What part of open source needs more open?
|
|
|
|
|
|
TOTO or not TODO? That is the question. What is the Matrix? That is the other question.
|
|
|
|
|
Abstraction layers in software are what architecture astronauts tell you to do. Instead, however, half of all applications out there would be so easy, fun, and most importantly: productive to implement if you just got rid of all those layers. "It's turtles all the way down."
|
|
|
|
|
This is like the perfect Animaniacs sketch... I miss that show...
GOOD IDEA: Remove layers that you don't need.
[Animation of Mr. Skullhead taking off his winter coat when it's a bright summer day]
BAD IDEA: Remove all layers.
[Animation of Mr. Skullhead taking stripping down all the way, and a passing granny beating him with her walker]
|
|
|
|
|
|
"Abstraction layers ... just got rid of all those layers."
Yes, get rid of the abstraction layers. Do not get rid of the separation-of-concerns/encapsulation layers (or whatever you want to call them).
|
|
|
|
|
Kent Sharkey wrote: if you just got rid of all those lawyers
Oh yes, please get rid of them
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Why would you want individually testable layers when a big ball of mud and "it compiles" is all the testing you need? I can't imagine.
|
|
|
|
|
I can imagine the sentiment, after having seen quite some "layers" that are merely glue. You've seen them - a class that calls methods on another class, often with the same name and the same parameters.
It's a generalization; people should not blindly add three tiers, but learn why there is a tier.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Indeed - and part of the problem is that people don't actually treat layers truly as layers - things that can be used individually and independently (and tested the same way).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
