Try statements in vb laziness?
-
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.
-
Colin Angus Mackay wrote:
exceptionally good practice, some might say
Uhhh.. *GROAN* :-D
-- Raaaaaaaaaaaaaaaaaaaaa!
I aim to please. :-D
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
-
I aim to please. :-D
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
You just had to throw that one out on us, didn't you? :rolleyes: :-D
-- Hey, TiVo! Suggest this!
-
You just had to throw that one out on us, didn't you? :rolleyes: :-D
-- Hey, TiVo! Suggest this!
Yes.... Well... It was too good not to throw that one out.
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
-
Yes.... Well... It was too good not to throw that one out.
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
Too bad on an ill-catching audience. ;)
-- Larva-Tested, Pupa-Approved
-
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
-
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 wrote:
And yeah, just about every method has Try ... Catch \ Throw \ End Try wrapped around it.
I've seen C# code like this. Don't blame it on VB. And the C# code was not written by a former VB developer either.
Kevin
-
Shog9 wrote:
And yeah, just about every method has Try ... Catch \ Throw \ End Try wrapped around it.
I've seen C# code like this. Don't blame it on VB. And the C# code was not written by a former VB developer either.
Kevin
I've seen C++ code like that. Point is, i haven't had to review any of it lately. 'Time comes, i'll go back to hating on C++ coders... ...'till the next "on error resume next" bug bites me. :doh:
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
-
I've seen C++ code like that. Point is, i haven't had to review any of it lately. 'Time comes, i'll go back to hating on C++ coders... ...'till the next "on error resume next" bug bites me. :doh:
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
I rarely maintain code in any language that is much better than mediocre in any language. That is, it's quite rare to see code written with the code maintainer in mind.
Kevin