This is the least of...
-
... the horrors in this WinForms app I'm working on...
catch (Exception ex) { string errormsg = ex.InnerException.ToString(); }Nice big NullReferenceException for you there mister. Other horrors include : Three separate layers of DB access code, one in VB, on in the Business Logic Layer, and one in a separate assembly (Written in VB!) :doh: :doh:
Smokie, this is not 'Nam. This is bowling. There are rules. www.geticeberg.com http://melpadden.wordpress.com
-
... the horrors in this WinForms app I'm working on...
catch (Exception ex) { string errormsg = ex.InnerException.ToString(); }Nice big NullReferenceException for you there mister. Other horrors include : Three separate layers of DB access code, one in VB, on in the Business Logic Layer, and one in a separate assembly (Written in VB!) :doh: :doh:
Smokie, this is not 'Nam. This is bowling. There are rules. www.geticeberg.com http://melpadden.wordpress.com
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
-
... the horrors in this WinForms app I'm working on...
catch (Exception ex) { string errormsg = ex.InnerException.ToString(); }Nice big NullReferenceException for you there mister. Other horrors include : Three separate layers of DB access code, one in VB, on in the Business Logic Layer, and one in a separate assembly (Written in VB!) :doh: :doh:
Smokie, this is not 'Nam. This is bowling. There are rules. www.geticeberg.com http://melpadden.wordpress.com
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."
-
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
// Dirty stuff goes here
#endifNot 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
-
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."
-
without trying to blow my own trumpet - take a look at my tip Preventing stubbed methods from being released[^]
-
Hey, look on the bright side - throwing a NullReferenceException in a catch block is better than just swallowing the original exception without logging or throwing anything else! :P
ekolis wrote:
Hey, look on the bright side - throwing a NullReferenceException in a catch block is better than just swallowing the original exception without logging or throwing anything else! :P
:mad: yeah, that's what made "On Error Resume Next" my least favorite phrase ever in a previous time.
-
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."
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.
-
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."
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. :sigh:
Curvature of the Mind now with 3D
-
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. :sigh:
Curvature of the Mind now with 3D
-
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. :sigh:
Curvature of the Mind now with 3D
-
Hey, look on the bright side - throwing a NullReferenceException in a catch block is better than just swallowing the original exception without logging or throwing anything else! :P
-
ekolis wrote:
throwing anything else
try{
//code here
}
catch(Exception ex){
throw new Exception("My crazy message");
}This is what you mean right? I've seen people do this, but I always wonder why ? Isn't it heavy doing this?
V.
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]
-
ekolis wrote:
throwing anything else
try{
//code here
}
catch(Exception ex){
throw new Exception("My crazy message");
}This is what you mean right? I've seen people do this, but I always wonder why ? Isn't it heavy doing this?
V.
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.