Best error handling option for a library that doesn't throw exceptions?

On program startup I need to configure a bunch of DIO yet the functions needed to do so return custom error objects rather than exceptions so I'm wondering if the best way to handle this is to 1) Throw my own exception after each failed call (as shown below) or 2) the old fashioned Goto ErrorHandler in place of the Throw and do a Throw from there or 3) something else I'm not familiar with yet.

vb.net Code:

ULStat = DIO24.DConfigPort(PortNum, Direction)
        If Not ULStat.Value = MccDaq.ErrorInfo.ErrorCode.NoErrors Then
            errmsg = "Error in ConfigureIO during DIO24.DConfigPort: " & ULStat.Message
            Throw New ArgumentException(errmsg)
        End If

Once all this is done I don't care about any other errors from this library elsewhere since they should never occur. It's stuff like "Board not configured", "invalid port number", etc that I need to catch at startup and close the program.

It doesn't sound to me like you need to take either option A or B. If you have to choose, then throw your own exceptions, but why bother? It sounds like you can just check for the errors and take action right away without even involving any error handling mechanism. After all, the error information returned isn't really an exception at that point, it's just a result that isn't what you wanted. It would be kind of like having a textbox that somebody didn't type anything into when you expected a number. You COULD handle that with exception handling, but you certainly don't need to, and exception handling is kind of slow.

The reason I want to raise an exception vs no error handler per se is related to the program not closing when I want it to if there is an error during startup. I don't want to use the old fashioned End, which was all over the place in the original VB6 code as well as various Stops, but Application.Exit still continues to process all the way to the end of the startup Form_Load routine before ending. It is the only form loaded but it spawns the next form (currently commented out while I'm building this) once all the init routines are complete. Thus, to make sure all the init routines will truly close the app if there's an error, I want exceptions to be thrown within them so the Form_Load's Catch can handle them.

Then it shouldn't be in the Load... if you need to test for something before a form loads, you should be using the application startup event.. if you have the Application Framework turned on (and I think it is by default) ... here... try this:
To access the Code Editor window for application events
With a project selected in Solution Explorer, click Properties on the Project menu.
Click the Application tab.
Click the View Application Events button to open the Code Editor.

In your application startup event, that's where you want to make your check. If it fails, then you cancel the event and the app shuts down. If it passes then let the code continue... the form will load and things will be OK.

-tg

Well that's a new event (to me). So you're saying I can run all the init routines (read INI, create db conn, config DIO, etc) in that event?

It looks like if any of those routines were to return an error string, for example, I could check for that and set e.Cancel. Then check for e.Cancel for subsequent routines and finally whether to either load the main form or dispose of anything that may have been created.

I had been using this particular form as sort of a splash screen to show progress while those things were being processed.

set e.Cancel then then Exit Sub immediately... no need to keep re-checking it... set it, then bail.


I wouldn't create a db connection, unless you're only using that to test for the db, and you close it. Ideally when you do need a connection, you create it, do your stuff, and close it... don't leave it hanging around. It's like shopping... get in, get what you want, and get out.

-tg

Quote:

---

Originally Posted by techgnome

I wouldn't create a db connection, unless you're only using that to test for the db, and you close it. Ideally when you do need a connection, you create it, do your stuff, and close it... don't leave it hanging around. It's like shopping... get in, get what you want, and get out.

---

I realize that is common wisdom for most apps, but we have always left them open (mfg plant) for speed. We're in no danger of running out. Perhaps I'm not gaining anything but it would seem that even with pooling that it would be faster not having to pull from the pool. For some apps it truly wouldn't matter since they are operator input, but this is a tester so I need to maximize throughput.

That is probably correct, but the gain is quite small. Pooling is very effective.

There are times when I would agree with leaving the connection open. If there is only one computer using the DB, then leaving the connection open isn't going to have any impact. If multiple systems could be working with the DB, then you might run into issues if you leave them open. Also, it depends a bit on the database itself. It sounds like you aren't running off an Access database, so you should be ok, but Access will corrupt itself, occasionally, if you leave a connection open and certain things happen.

In any case, I think you are doing what you are doing for a sound reason. It may or may not be right, and you may or may not run into any trouble, but I'd say: Carry on, until you find sound reason to do otherwise.

Unless you are constantly writing and/or reading from the database, even in an industrial situation with a very well defined - and narrow - activities, closing the connection after use is still the way to go.

I have an app that updates a display every 5-10 seconds or so, reading from a database (industrial setting). It still opens, reads, closes. Indeed, if something happens to the connection, it fails gracefully (at the connection) rather than maintaining a connection through database connection failures.

It's quite common for libraries to not throw exceptions. Indeed, Win32 calls often don't throw any exceptions, just returning an error code, or success/failure, and you have to GetLastError. Usually, the return result indicates the error (if a specific value such as -1) or the value required. There's generally no need to throw any exceptions if you are just going to handle it, unless you need to handle it further up the chain. Even then, follow the same pattern, returning an error code, may result in better and cleaner performance.

Quote:

---

Originally Posted by Shaggy Hiker

In any case, I think you are doing what you are doing for a sound reason. It may or may not be right, and you may or may not run into any trouble, but I'd say: Carry on, until you find sound reason to do otherwise.

---

It's been done this way for a couple decades now with no adverse effects that I'm aware of at least. Back end is always Oracle or SQL Server and even the former does it. Perhaps not in SQL Developer (I've never checked), but I know using SQL*Plus the connection is always open. I guess technically I can't say that since I don't know for certain how to check. The session on the server is always open.

Quote:

---

Originally Posted by SJWhiteley

There's generally no need to throw any exceptions if you are just going to handle it, unless you need to handle it further up the chain. Even then, follow the same pattern, returning an error code, may result in better and cleaner performance.

---

In this case it's program startup so there's nothing the operator or program can do to fix it so I was trying to get everything caught in the main Catch on Form1_Load so further initialization routines were not run if an error occurred. The program needs to close and they need to fix the issue raised. That proved to be more challenging than I expected. For example, I had to initialize a serialport on Form2. I was doing it in Form2's Load event (via Show method called from Form1) and the exception was being thrown but nothing was done with it when it passed back to Form1's Load event. I didn't expect that since I've read in several places that an exception will continue to bubble up until it gets to a Catch (or crashes). I did get it to work if I opened the port in Form1's event but didn't like having the form's code separate from the form so I moved it to the constructor of Form2 (no need for Show method now, which I assume was part of the problem), which is likely where it belongs anyway.

Back to database connections though. Other than potential better management of resources (ie, large user base using many apps), why is closing the connection after each call so important (or at least preferred)? I can see if the program crashes hard it would stay open on the server until the session times out, you'd have some unreleased memory on the PC, but that is extremely rare (in my case at least). Is it more robust after network glitches? I'll admit VB6 never seemed to be that good at reconnecting network drives after a network issue (usually a power outage which were quite frequent) - we'd always just restart the programs.

I have thought that "other than potential better management of resources", there wasn't anything...except for when connected to Access, because a network glitch when an Access DB is connected to can be a disaster. That doesn't apply to SQL Server, though, as far as I am aware. I have always thought that the only reason to get in/get out quickly was about resource management, so I'll be interested to see what others have to say about it.

It's resource management, not just on the client but on the server as well. It's easier for the server to manage 5 connections in a pool than 50 potentially active connections. there's also a possible issue with data integrity, as it prevents potential transactions from being left open and uncommitted, which will cause a pile up real quick. Lastly, it's jsut about general stablity from the client side. I've seen this happen, where something heavy gets dropped, it some how manages to find that one LAN cable on the floor somehow, and snip it off... I've seen routers & switches knocked over, snagged on something and ripped out of their wall sockets. Let's face it manufacturing floors are not exactly IT-friendly. Either way, it's been severed from the server. It's actually far easier to check for a connection by seeing if you can even open it, rather than assuming it is (and just because the state of the connection is "open" doesn't mean it's valid, if the line is cut, the client will continue to think it's open until you actually try to use it) and attempting to update data to a server that's suddenly no longer there.

Just my views. I see it as a stabler, consistent foundation to work from.

-tg

I would not touch Access with the proverbial 10 foot pole. :)

Quote:

---

Originally Posted by techgnome

It's resource management, not just on the client but on the server as well. It's easier for the server to manage 5 connections in a pool than 50 potentially active connections. there's also a possible issue with data integrity, as it prevents potential transactions from being left open and uncommitted, which will cause a pile up real quick. Lastly, it's jsut about general stablity from the client side. I've seen this happen, where something heavy gets dropped, it some how manages to find that one LAN cable on the floor somehow, and snip it off... I've seen routers & switches knocked over, snagged on something and ripped out of their wall sockets. Let's face it manufacturing floors are not exactly IT-friendly. Either way, it's been severed from the server. It's actually far easier to check for a connection by seeing if you can even open it, rather than assuming it is (and just because the state of the connection is "open" doesn't mean it's valid, if the line is cut, the client will continue to think it's open until you actually try to use it) and attempting to update data to a server that's suddenly no longer there.

---

It's true things are rough on the floor but I've been incredibly lucky the 20 years I've been doing this now (other than all those power outages). I hadn't been in that plant for 5 years and while I was there recently for just a few hours the power went out in half the facility. SMH

I'd have to go refresh my memory again, but I don't think Oracle could care less how many connections it has (provided you have it set up properly). It's certainly not any strain at all. Been a while since I did all the DBA exams and I'd guess it's better now. I'd assume SQL Server is similar. Regarding the network "glitches", it's going to fail no matter what so I'd guess if you have it retry on a timer that would be more user friendly than have to restart the app. I could re open the connection I suppose.

At the end of the day, two things are a given: 1) It has to work, it doesn't have to be pretty, it just has to work. 2) you know your app and environment better than any of us.

On a partially related note - there was a time when MS sold Client Access License (CALs) for SQL server... for each concurrent connection you had, you had to have a CAL to go with it. So if you had 5 CALs, you could (theoretically) have only 5 concurrent users at any given time. I think this is one of the driving reasons why there was a push to the get in, do, get out design. It was a big pain, and I don't think it lasted very long. It's certainly not a problem now.

-tg

Quote:

---

Originally Posted by techgnome

On a partially related note - there was a time when MS sold Client Access License (CALs) for SQL server... for each concurrent connection you had, you had to have a CAL to go with it. So if you had 5 CALs, you could (theoretically) have only 5 concurrent users at any given time. I think this is one of the driving reasons why there was a push to the get in, do, get out design. It was a big pain, and I don't think it lasted very long. It's certainly not a problem now.

---

THAT would be a good reason. :)

Back to the topic somewhat... any comments on what was going on with why Exceptions were not handled in my comment above (copied here):

Quote:

---

For example, I had to initialize a serialport on Form2. I was doing it in Form2's Load event (via Show method called from Form1) and the exception was being thrown but nothing was done with it when it passed back to Form1's Load event (which was wrapped in a Try...Catch...Finally). I didn't expect that since I've read in several places that an exception will continue to bubble up until it gets to a Catch (or crashes). I did get it to work if I opened the port in Form1's event but didn't like having the form's code separate from the form so I moved it to the constructor of Form2 (no need for Show method now, which I assume was part of the problem), which is likely where it belongs anyway.

---

I don't trust the Load Event. You may already know the issue about exceptions raised in the Load event, but you wouldn't be the first to report some unusual activity when exceptions get handled in that event. Load is just different.

Load was the old standby in VB6 so I guess I'll get used to using the Sub New where it seems appropriate.

I would agree with SH regarding the load event.

Unless you have some form controls that need initializing before the 'work', just use the application events Startup to do your work. The form should only do things related to the form itself.

Further, I'd reiterate not using exceptions in this case. As already noted, exceptions are expensive. Why not simply return true or false from a routine to indicate success or failure? If it fails then don't continue. It isn't a hard and fast rule, but it's what I'd do, in the situation you are in.

Quote:

---

Originally Posted by SJWhiteley

Further, I'd reiterate not using exceptions in this case. As already noted, exceptions are expensive. Why not simply return true or false from a routine to indicate success or failure? If it fails then don't continue. It isn't a hard and fast rule, but it's what I'd do, in the situation you are in.

---

Largely because the expense doesn't concern me at startup and I like having the StackTrace info to pinpoint what happened (hopefully). Once running, most of my functions do return boolean and pass an error message back if one was trapped.

Wouldn't an Exit Sub from Form_Load just cause the program to hang (assuming form isn't shown yet) or will that fire some other event? I'd rather go to the Finally statement so it cleans up anything that got created. Is there some "goto Finally" type command? :) That's kind of what I was expecting Application.Exit to do rather than continuing with the rest of the routine.

Maybe what you want is the Application Startup event then, instead of the Load... it's more reliable and flexible in what you can and can't do. From the Startup event, you can cancel or allow it to continue based on conditions. With a form load event, you're going to get the form no matter what. Ungh... there was another thread recently where a similar discussion took place. if I can find it again, I'll post it. It's got all pertinent (and some not so) links and info about the event and how you might be able to use it.

-tg

drp - the is the thread I was thinking of... I just didn't look back through the posts well enough...
so... how did we get back to putting stuff into the load event?

LOL. We've kind of come full circle, huh? :) I never removed them from Load since I had gotten it to work close enough to like I wanted for now. Unfortunately, I'm under a time crunch so don't want to keep changing stuff if I don't have to. If I can copy and paste it all into the Startup event and it works the same I'd be OK with that. I just don't want to exit the program without seeing a StackTrace of what the issue is, hence my desire for Exceptions. Once it's going, it pretty much runs itself. There was very little error handling in the VB6 code.

well, the good news is that if the other component returns an error code (instead of an exception) 1) you know what the problem is - the error code tells you so, and 2) you know where the error happened since you called it... so that's really all you need for a "stack trace" ... it may not be complete and robust as you like, but that's what it is. It's not like you're going to be able to go into the code for the component and start "fixing" it. Any errors you get out of it should be known and usable errors... You should care that it was 5 calls deep or 50 calls deep (and I've seen some stack traces that really push that limit on me!). But to each their own. My personal preference is to jsut have the component tell me success or failure and in the case of a failure, some descriptor that I can use to provide something friendly to the user.

-tg

Quote:

---

Originally Posted by topshot

...
Wouldn't an Exit Sub from Form_Load just cause the program to hang (assuming form isn't shown yet) or will that fire some other event? I'd rather go to the Finally statement so it cleans up anything that got created. Is there some "goto Finally" type command? :) That's kind of what I was expecting Application.Exit to do rather than continuing with the rest of the routine.

---

I have only skimmed this thread, so apologies extended if this has been stated previously.

"Exit Sub" is safe; it is the same as a Return statement. See: https://msdn.microsoft.com/en-us/library/t2at9t47.aspx

There is a glitch in 64-bit WinForms (don't know if that is relevant to this case) that silently fails (while in debug) any exceptions thrown in the Load event that are not trapped in Try-Catch, so I would recommend moving the logic to the Form.Shown Event. see: https://connect.microsoft.com/Visual...-visual-studio

As far as "goto Finally", that can be done with this pattern.

Code:

---

Try
  Application.Exit() ' request orderly shutdown, Form.Closing handler can stop shutdown by setting e.cancel = True
  Exit Sub ' same as a Return,  no code after this block is executed except for code in the Finally block
Finally
  Debug.WriteLine("from Finally")
End Try
' anything placed here will be skipped.

---