|
That is one way to do it, though I was thinking more along the lines of a custom exception, and (if it makes sense in the situation) including the original exception:
[code]
try {
// code here
}
catch (Exception ex) {
throw new MyApplicationCustomException("Oh no! Something went wrong! For more details see the inner exception...", ex);
}
[/code]
|
|
|
|
|
My current work project (code base from another company) is full of these, though wrapping in custom exception types and preserving the inner exception.
It makes sense when you want to add extra semantic information to the exception because you know the context in which it was called. It doesn't the amount they've done it (and it makes tracking down the actual point of failure a pain).
It is 'heavy', yes, but of the order of milliseconds, and if you're using exceptions properly (i.e. they are only thrown in exceptional circumstances) that doesn't matter.
|
|
|
|
|
Mel Padden wrote: Three separate layers of DB access code, one in VB, on in the Business Logic Layer
Yes, that is a horror itself. Last I checked, that what the Business Logic Layer is for, to be the bridge between the application and the database.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
People write this sort of stuff while debugging and forget to remove it. "Ok so what exception is being thrown. I'll write a try catch and see. Problem solved" but you forget to remove the catch statement.
Does any one know of a nice solution so you can debug but ensure that this sort of rubbish doesn't end up going out the door.
"You get that on the big jobs."
|
|
|
|
|
#if DEBUG
#endif
Not very clean, but somewhat safer.
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
|
|
Does any one know of a nice solution so you can debug but ensure that this sort of rubbish doesn't end up going out the door.
Only by using pre-compilation tags like #Const and #if-then-else. Set your constant to one value (say True) while debugging, then set it to False as you wind down debugging. C has a similiar capability with a few more options, and I used to use this facility to allow trace statements to appear during development and disappear at time of release simply by changing the value of a constant.
|
|
|
|
|
One developer I worked with used to like
Assert(DateTime.Now < new DateTime(2011, 10, 1))
He'd check stuff in and it would break in QA a few days later.
|
|
|
|
|
OMG - I can't think many coding faux pas worse than that - fingers/hammer combination seems to be all I can recommend - I see you are in the States so hopefully I will never have to work with him
|
|
|
|
|
|
A friend of mine wrote this little pearl a while ago. When I took the keyboard and wrote "true", we laughed for a good 5 mins. ...the next step was getting rid of the crazy infinite loop.
while(Convert.ToBoolean(1))
{
}
|
|
|
|
|
while(true) is one of my pet hates.
"You get that on the big jobs."
|
|
|
|
|
Why?
Oxfords English < Official CCC Players Dictionary
Excuse me for my improper grammar and typos.
It's because English is my primary language, not my first language.
My first languages are C# and Java.
VB, ASP, JS, PHP and SQL are my second language.
Indonesian came as my third language.
My fourth language? I'm still creating it, I'll let you know when it's done!
|
|
|
|
|
while(true) isn't self-documenting
while(true)
{
.... lots of code
if(drunk) break;
drinkBeer();
.... lots more code
}
I much prefer
while(!drunk)
{
.... lots of code
drunk = true;
if(drunk) continue;
drinkBeer();
.... lots more code
}
Although its probably just the drink beer bit I really like
"You get that on the big jobs."
|
|
|
|
|
RobCroll wrote: while(true) isn't self-documenting
Guess that's where comments comes in handy.
RobCroll wrote:
while(true)
{
.... lots of code
if(drunk) break;
drinkBeer();
.... lots more code
}
I much prefer
while(!drunk)
{
.... lots of code
drunk = true;
if(drunk) continue;
drinkBeer();
.... lots more code
}
I'm a fan of while(true) but the first is simply garbage, I never used it like that.
Oxfords English < Official CCC Players Dictionary
Excuse me for my improper grammar and typos.
It's because English is my primary language, not my first language.
My first languages are C# and Java.
VB, ASP, JS, PHP and SQL are my second language.
Indonesian came as my third language.
My fourth language? I'm still creating it, I'll let you know when it's done!
|
|
|
|
|
You've got my interested now. So how do you use while(true) without coding garbage like break; (or return)?
"You get that on the big jobs."
|
|
|
|
|
No, no, don't misunderstand me. I use break;, continue;(above loop) or return;
It's the context that I disagree with (ie. if you can make it simple with just a boolean, why do you need a while(true)?).
Oxfords English < Official CCC Players Dictionary
Excuse me for my improper grammar and typos.
It's because English is my primary language, not my first language.
My first languages are C# and Java.
VB, ASP, JS, PHP and SQL are my second language.
Indonesian came as my third language.
My fourth language? I'm still creating it, I'll let you know when it's done!
|
|
|
|
|
I actually have a LOT of While 1=1 in MS SQL...
It's very cool, works great, and I just love to see the face of programmers when I show them with pride my nested while 1=1 loops in recursive stored procs...
|
|
|
|
|
I think we all know that writing software is a matter of black and white. There may be many different ways to successfully solve a given problem, but the different methods will produce concrete results - unless you are writing in Prolog, then you may not know the outcome. We also tend to find a method that ‘works for us’ and continue to use that same sequence of code to solve similar problems.
A programmer working with me many years ago either had a short attention span or leaned on his professors’ admonition that everything in the world is gray… He would never reuse a snippet that worked and because we were asked to comment our code (this was back in cryptic Assembler/Fortran land) he would liberally sprinkle ‘THIS MIGHT WORK’ anywhere there was questionable logic.
Lesson: Don’t hire Philosophy Majors for Dev projects!
Gray beard, but no holey tee-shirts, 50+ yrs writing software.
|
|
|
|
|
Frank Towle wrote: Lesson: Don’t hire Philosophy Majors for Dev projects!
FTFY
|
|
|
|
|
@Bert, that's not P.C. you know
|
|
|
|
|
|
Actually, Edsger Dykstra pointed out in the early '90s that computer science programs were producing inferior programmers compared to other programs, most notabley physics, math, psychology...and philosophy.
What you have there is simply a compulsively honest nerd. Don't blame the higher education, I assure you this set of habits probably got ingrained somewhere in elementary school.
|
|
|
|
|
Obviously it's not, I got 1-voted for it. But it was 100% worth it.
|
|
|
|