Try statements in vb laziness?
-
No, just the VB part. :rolleyes:
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
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
-
No, just the VB part. :rolleyes:
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
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 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
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
-
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)
-
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
Just out of curiosity what is wrong with Implementing a Try / Catch / End Try in each method?
Mike Lasseter
-
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
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
-
Just out of curiosity what is wrong with Implementing a Try / Catch / End Try in each method?
Mike Lasseter
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
-
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
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
FileOpenis 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
-
using try statements in vb.net bad programing practice.
-
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
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
-
GregScott wrote:
is using try statements in vb.net bad programing practice
Depends on who you talk to and their thoughts on exception handling...
-
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
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
-
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
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 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
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 SubMike Lasseter
-
Using Try Catch Finally can be very good programming practice (exceptionally good practice, some might say) if used correctly.
Upcoming events: * Glasgow: SQL Server 2005 - XML and XML Query Plans, Mock Objects, SQL Server Reporting Services... Never write for other people. Write for yourself, because you have a passion for it. -- Marc Clifton My website
Colin Angus Mackay wrote:
exceptionally good practice, some might say
Uhhh.. *GROAN* :-D
-- Raaaaaaaaaaaaaaaaaaaaa!
-
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
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.
-
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 SubMike Lasseter
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 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
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
-
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
You need one Try-Catch around the Application.Run() call and register an event handler with Application.ThreadException to handle non-fatal exceptions. For exceptions on other (non-UI) threads, a global handler registered with AppDomain.CurrentDomain.UnhandledException will suffice. That should take care of all exceptions at the highest level (where you can log and/or display them). There's no need to use Try-Catch in every OnClick method. For the rest of the program, only handle exceptions that you can fix.