Try statements in vb laziness?

Kevin McFarlane

No.

Kevin

Shog9 0

No, just the VB part. :rolleyes:

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

Fred_Smith

Shog9 wrote:

No, just the VB part

You just couldn't resist, could you? :) I've got a headache today X| , so you're spared... (And no, it isn't because I've been....) Fred

Marcus J Smith

Why I oughta! ;P

CleaKO

"Now, a man would have opened both gates, driven through and not bothered to close either gate." - Marc Clifton (The Lounge)

Shog9 0

Fred_Smith wrote:

You just couldn't resist, could you?

Nope. ;) I've been reviewing VB.NET code from a consultant. He's working on porting a VB6 library to VB.NET, and cleaning it up along the way. The original code was... really awful, so i have a lot of sympathy for him... but still, i would never ask for a review of code that looked like this. I tell ya, every time my attitude towards VB starts to soften, i end up seeing VB code, and then all the bitterness just comes rushing back. And yeah, just about every method has Try ... Catch \ Throw \ End Try wrapped around it. :doh:

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

Shog9 0

CleaKO wrote:

Why I oughta

...learn a real language? I agree! ;P (sorry, that was just too tempting...)

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

mr_lasseter

Just out of curiosity what is wrong with Implementing a Try / Catch / End Try in each method?

Mike Lasseter

Fred_Smith

I refuse to port code - even my own! It's quicker, easier, (and therefore cheaper) and a whole lot more enjoyable, to start over... Classic ASP to ASP.NET? Not on your life... Fred

Shog9 0

Two things:

It is laziness - rather than identifying the specific exceptions that might be thrown and handling just the ones that can actually be handled effectively, all exceptions are caught... and, not handled.
Blindly re-throwing exceptions just makes debugging harder. And since the low-level code isn't doing anything to interpret specific exceptions, high-level code is forced into the same pattern of blindly catching all exceptions.

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

Shog9 0

Well, the original library was in rough shape, nearly unmaintainable, and yet crucial to the operation of the program. I encouraged the developer to re-use as little of the actual code as possible, but i guess he thought it would be quicker to try it anyway. For me, the first shock came with seeing that FileOpen is still even supported in VB.NET... :wtf:

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

Paul Brower

using try statements in vb.net bad programing practice.

mr_lasseter

I would agree with you in your business layer you should not handle any exceptions that you can't fix. But in the UI I think it is a different story, I would think in the UI you want to catch all exceptions so you could: 1. Log the exception 2. Display the error to the user without the application exiting abruptly.

Mike Lasseter

led mike

Paul Conrad wrote:

Depends on who you talk to and their thoughts on exception handling...

No it doesn't and neither does gravity.

led mike

Shog9 0

Even in the UI, i'm a bit uncomfortable catching exceptions that can't be reasonably handled... but i'll allow that it might be useful in a few specific cases. Of course, you wouldn't re-throw the exception in those cases either.

----

i hope you are feeling sleepy for people not calling you by the same.

--BarnaKol on abusive words

led mike

mr_lasseter wrote:

But in the UI I think it is a different story, I would think in the UI you want to catch all exceptions so you could:

Not really. In general you don't want anything but rendering logic and user interface event handling in the presentation layer.

led mike

mr_lasseter

What is it that you mean by user interface event handling? I would think you call the following event handling and in the following if the Load method failed (due to the database being unavailable) wouldn't you want to inform the user the the database is down? Private Sub MyButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyButton.Click BindingSource.DataSource = BusinessObject.Load() End Sub

Mike Lasseter

Jorgen Sigvardsson

Colin Angus Mackay wrote:

exceptionally good practice, some might say

Uhhh.. *GROAN* :-D

-- Raaaaaaaaaaaaaaaaaaaaa!

Nemanja Trifunovic

Fred_Smith wrote:

I refuse to port code - even my own! It's quicker, easier, (and therefore cheaper) and a whole lot more enjoyable, to start over...

Depends on the technology, design, size of the project... I worked on a project that was ported back and forth between Windows (16/32 bits), OS/2, Mac OS and different flavors of Unix - rewriting it from scratch was never an option - it was huge and designed for portability.

Programming Blog utf8-cpp

led mike

mr_lasseter wrote:

BindingSource.DataSource = BusinessObject.Load()

Your model should not load when you are ready to bind. It should load "on it's own" and handle the exception and publish the exception as an event that is handled by the presentation layer. When that scenario occurs, at binding time, the "DataSource" should be a valid state technically but would of course be empty.

led mike

mr_lasseter

led mike wrote:

It should load "on it's own"

How? In my example the BusinessObject is loading itself, but only when the UI requests that it should be loaded. The BusinessObject doesn't have any idea that it needs to be loaded.

led mike wrote:

handle the exception and publish the exception as an event that is handled by the presentation layer.

What benefit does this provide over catching the execption in the button click event and passing that exception to a class that handles the exception (logs and displays a message to the user)?

Mike Lasseter