Design Control and Try/Catch

The real subject of this might well be the usage of exceptions, but first I wanted to discuss design control so that the usage of exceptions can be placed in perspective.

I do not have a clear picture of how the Design Control process is carried out in Computer Science. My own background is engineering (chemical) and the Design Control process is very robust and is The integral piece in the design/development of any system of any type. I have been going through some documentation for software system (application) design and have not been able to find anything that I would consider to be an adequate Design Control Process. That does not mean it does not exist, but just that I have not found them. I am aware that there are some out there, GAMP comes to mind, but I have never been a fan of GAMP (it's personal). However, I have implemented many software systems into many chemical production systems over the years and have had some experience with software system design control. So that is the background for my real subject which is FMEA (Failure Mode Effects and Analysis) and the usage of exceptions.

For those of you who might not be familiar with FMEA's and their usage let me explain. The short explanation is that an FMEA is formal documentation of everyone's best idea of what can fail in a system being designed (prior to even starting the design) and how to remediate/resolve those failure modes. The FMEA is updated as the design goes forward. I have reached a point in my learning of software system design that I am now thinking about how to carry out a formal Design Control for the applications I am attempting to develop.

To that end I have found myself beginning to use exceptions as not just a debugging tool, but as part of remediation for identified failure modes. I have identified two primary types of failure modes in the software systems I am working on or have observed. The first are those failure modes that occur in the operation of the software system, i.e. contamination of the code causing an error. The other type is user interactions with the software system, i.e. the entry of the wrong type of data into an input.

I have lately been using a lot of Try/Catch exceptions for both debugging and for remediation of certain failure modes. What the Try/Catch offers is the ability to, when an failure occurs, provide a means to continue the application without it breaking down and, where possible, to provide a means of correcting the failure. However, what concerns me is the cost (in application efficiency) that using these might entail.

Now I have an application that has a rather large number of Try/Catch routines for debugging purposes and for failure remediation purposes. The first case really is to cover all of those failure modes that might fit into the software operation type. Certainly they can be taken out when the design/development is complete, but I would prefer to leave them in, in the event that something might effect the code at critical points in the running of the applications. The second case is the user interface failure modes, and I would very much prefer to keep all of those them in for those.

It is my understanding that the efficiency of the application can be reduced (in terms of an increase in processing time) to use Try/Catches as a remediation tool, which slowly and painfully brought us to the simple and seminal question I have. It is my understanding that using the Try/Catch methods can increase processing time. What I most need to understand about this is that unless the Try fails and the Catch is executed how is processing time increased? It seems to me that processing time should only increase when the Catch is executed. Is this true?

If no exception is thrown, the cost of Try....Catch is zero (unless you count the time it took you to write it). However, if an exception IS thrown, the cost is between high and VERY high. For that reason, exception handling should be used only for those situations where you can't check for the problem. User input can always be validated, so it's not a reasonable place for exception handling. Database activities will always have the potential to throw exceptions for reasons you can never check for ahead of time. Therefore, database activities should always be handled in Try...Catch blocks. Of course, anything you can reasonably check for in the DB activity should be checked for, but there are some cases that you can't check for.

The efficiency issue relates only to throwing exceptions. You can have millions of exception handlers in your code and performance will be basically unaffected unless an exception is actually thrown. That is why it is recommended not to use exceptions for controlling the flow of execution. For example, this is bad:

vb.net Code:

Try
    Dim result = NumericUpDown1.Value / NumericUpDown2.Value
 
    '...
Catch ex As DivideByZeroException
    MessageBox.Show("Please enter a non-zero divisor.")
End Try

and should be written without exception handling:

vb.net Code:

If NumericUpDown2.Value = 0D Then
    MessageBox.Show("Please enter a non-zero divisor.")
Else
    Dim result = NumericUpDown1.Value / NumericUpDown2.Value
 
    '...
End If

Exceptions should only be used to catch exceptional situations and invalid user input is NOT an exceptional situation. Validation before the fact should almost always be preferred to exception handling after the fact because of the fact that throwing the exception is expensive. If it is very unlikely that an exception will occur then you may prefer the exception handling over the validation because one expensive operation may be more acceptable than many inexpensive ones. This may be most important in a loop, where validation on every iteration may be just as expensive as one exception that will probably never occur.

Thanks Shaggy. I was really concerned about that time thing and I am glad to know what the reality is on that.

What you say about the validation of the user inputs is true and suggests that the Try/Catch is only useful until all user failure modes are identified and each remediation built into the code (which should occur during design/development). Additionally, I can also see that no matter how hard you try you can almost never predict what can occur with/in the code during operation so identification of failure modes, prior to occurrence of the failure so there is really very little that can be done during design/development.

I am rapidly learning about what you stated about databases and their ability to generate all sorts of crap whether you are careful or not. That is where I have found almost all of my Try/Catch blocks are used.

Thanks. Do you happen to have or know any good reading material on Software Design Control (besides GAMP). I do not want to re-invent the wheel if there is a good one already out there.

Also, thanks JM (I hit the reply before finishing). Both of you provided me with the information that I was most concerned about. Same question to you. Do you know or have any good reading material on software design control?

It's very difficult to determine exactly how exception handling should be implemented until you write the code. You can get a general sense of what tasks might generate exceptions before writing your code but you won't know exactly what exceptions could be generated where until you actually write it. Two developers might implement the same task in two different ways and thus require quite different exception handling.

Exception handling should generally only be used where something is beyond your control. In my example above, it's fairly easy to ensure that you never divide by zero so you really should never encounter a DivideByZeroException. When it comes to accessing things like files and database, there's no way that you can ever guarantee that certain operations will succeed, so exception handling is a must. All applications should also include a global exception handler (e.g. handling the UnhandledException event in a Windows Forms app) so that your app never simply crashes but rather logs unexpected exceptions and closes gracefully.

Yeah, I don't design my exception handling up-front. It's something I think about as I go along. The rule of thumb is "a method should do what it says or throw", but experience teaches you the reality is more complex.

For example, think about a simple routine that fetches data from a data file. In some situations, "file not found" is catastrophic and you need that exception to "bubble up" through your application and result in termination. In other situations, "file not found" might mean "no file has been created yet". I might decide that can mean the same thing as "there is no data" and return no results.

So "What do I do when something throws an exception?" has to be decided case-by-case in the context of your application. It's more art than science, and we can't make a tutorial outside of "how to throw" or some rough "here are your choices and when they tend to work" guidelines.

There is where a robust design control process needs to be determined. There is nothing different in this than in the world of Chemical production where I came from. No matter what you do a reaction, how to produce it, how to control it and how to yield exactly what you want something that cannot completely be predicted. Add to that, that there numerous ways to skin a cat and if you are not careful you have chaos. So what has to be done is before you even begin building anything you need to first define exactly what you want. What that is, is a set of user requirements and functional requirements. From those you have the broad strokes for what the design will consist of. These will also dictate, to a large degree, much of the detail for how to meet the requirements.

At this point, if you know specifically what it is you want out of a design you can then determine the different ways that the requirements can be met and from there select the ones most suitable for the overall design. The bottom line, however, is whatever one is working on, be it a chemical system, building a car and even a software system it must be treated as a process. A process might be described as all of the things involved in starting at a point and reaching an end and includes every variable that affects the process as well as the inputs and outputs of the process. Now that is not to say that as the design goes forward that changes do not occur and glitches will always bubble up. Some can be overcome and some cannot and redesign might even be required.

Having said all of that nothing should ever be treated as an art. Everything can be turned into a science. Now that I have said all of that I will honestly state that since I have retired everything has become an art and I don't do science much anymore. But I can that software actually contains fewer variables and is less susceptible to process variability and less complex than many of the things I used to work with and I am beginning to yearn for science instead of art.

So I am beginning to be drawn back into the world where a designer/developer would use all of the tools of Design Control to remove art from the process and replace it with science. I guess it is just in my DNA. At any rate, I like the Try/Catch as one of the tools at my disposal to help deal with failure modes. One more thing, were you to define a full set of requirements, complete a detailed flow chart of the process and then run a FMEA prior to starting I am certain that those things alone would significantly reduce the number of oops you typically might run across in your development process. I will also say that art is, if nothing else, very interesting and were it not for my old training and skills starting to kick back in would continue to work at the art instead of the science.

"Can I up-front design my software and does it provide benefits?" is an age-old software development argument. It doesn't "die" because the answer is different for every project. Maybe you are in a situation with problems that are predictable and 2 different customers want them handled the same way. That's a blessing in most software, it's more likely if you have 2 customers you will get 8 different sets of requirements for any given behavior depending on when and how you ask.

I sort of feel like I don't know what question is being asked.

Everything you have said there has been said before. Books have been written about it. Polemics have been written about it. And they all have one thing in common: They are laughably wrong in hindsight....though people only laugh because the alternative is to cry.


Rigidly defined user requirements and functional requirements? I'd LOVE it if my users knew what they wanted. I've never had the luxury. At best, they have a feel for how they'd like to interact with the computer, but even that is rare. Mostly they want to be able to get their data into the system and get it back out. They want this to take no time at all, and should anticipate their needs and supply them at the moment they are needed. Fortunately, my users recognize that's an impossible ideal, and just want me to get as close to that as I can.

Nothing should ever be treated as an art? People have been trying to turn programming into a science for at least forty years, by now (and probably longer). Every attempt has ended in dismal failure. Not even a hint of success has been arrived at. The closest you can get is probably the process that created the code for the space shuttle program, but that cost some $20,000 per line of code, which is far from commercially acceptable. Everything else ends up just being semi-guided creativity, while those who try to call it a science gnash their teeth in frustration at yet another failure of their dreams.

If you want to try, go right ahead. You can find your way by walking across the bodies of those who tried in vain before you.

Quote:

---

Originally Posted by Shaggy Hiker

Everything you have said there has been said before. Books have been written about it. Polemics have been written about it. And they all have one thing in common: They are laughably wrong in hindsight....though people only laugh because the alternative is to cry.


Rigidly defined user requirements and functional requirements? I'd LOVE it if my users knew what they wanted. I've never had the luxury. At best, they have a feel for how they'd like to interact with the computer, but even that is rare. Mostly they want to be able to get their data into the system and get it back out. They want this to take no time at all, and should anticipate their needs and supply them at the moment they are needed. Fortunately, my users recognize that's an impossible ideal, and just want me to get as close to that as I can.

Nothing should ever be treated as an art? People have been trying to turn programming into a science for at least forty years, by now (and probably longer). Every attempt has ended in dismal failure. Not even a hint of success has been arrived at. The closest you can get is probably the process that created the code for the space shuttle program, but that cost some $20,000 per line of code, which is far from commercially acceptable. Everything else ends up just being semi-guided creativity, while those who try to call it a science gnash their teeth in frustration at yet another failure of their dreams.

If you want to try, go right ahead. You can find your way by walking across the bodies of those who tried in vain before you.

---

I agree. Getting a well defined product definition from my customers was one of the hardest things of the whole custom software process. Most people would be to busy or just get a annoyed when I start asking questions, even when I'd explain that the more clear the picture I initially have will save them money.

A shorter version of my post that finally came to me makes more sense in light of those replies:

I'd argue if we made a number line for "kinds of projects", we'd have two extremes.

Far to the left, on the "rigid" side, we'd have projects like the Space Shuttle guidance system. This is not art, it's completely science. All it does is implement a giant calculator. You can formally verify these projects and design them up-front.

To the right, on the "agile" side, you have projects like Facebook. When they are being designed, they're trying to solve a problem that some might argue doesn't exist, or at least no one knows they have the problem. You can't design the project up-front because no one knows what the solution looks like.

I am most well-versed in projects that fall more to the "agile" side of that line. All of my advice and biases will be shifted towards that side of the line.

I don't agree with statements like, "nothing should ever be treated as an art" because I feel it ignores that there are two extremes with a gradient between them, and that most projects do not match either extreme. It would be just as foolish for me to believe, "aeronautics guidance software should be designed iteratively with no up-front design".

NASA didn't go into a cave and emerge 10 years later with Apollo blueprints that worked perfectly on the first build. There were dozens of iterations, and some people died in the process of discovering flaws. Science is tough to nail down when it's "science no one has done yet."

There have been exactly two times that I can count in the last 25 years of development where I had customers that new what they needed/wanted and could articulate it to the point of hard and fast requirements that could be documented ahead of time. Both times were in the Air Force. Both times were in situations that processes were so strict, that it left no doubt as to what happened in alternate flows, because alternate flows did not happen. One was a replacement tool that allowed communication to happen via email between the secure and unsecured networks. The other was tracking inbound documents (of all kinds of levels of security clearance, ranging from unclassified to the so classified, that is existence is denied) through out the building. Those are the only times ever that I had concrete requirements that could be documented before development. They are also the only time I've had documents I've written that passed ISO 9000 compliance. (come to think of it, they're probably the only ones ever sent for compliance certification).

-tg

Quote:

---

Originally Posted by techgnome

They are also the only time I've had documents I've written that passed ISO 9000 compliance. (come to think of it, they're probably the only ones ever sent for compliance certification).

-tg

---

Ah, that sounds like an ISO-metric exercise.

Oh yeah. I clearly remember how hard it can be to get user requirements. But if you don't get them (one way or another) you will never be able to deliver a product that fully does what is needed or wanted. Frequently the customer will never actually provide you with a useful set of user requirements and it is left to you to figure it out as best you can.

In reference to the Right Side (agile) the same process would apply. Any kind of design project for anything will always have problems that do not currently exist. This is even true for very mature processes that are being designed. And one thing that is always true is that you don't know what you don't know (the 1st rule of engineering).

This is where a FMEA comes in. The whole purpose is to noodle out all of the failure modes (problems really doesn't cover the situation very well so let's use more explicit terminology) that you know will occur, those you believe might occur and, hopefully, define many that never otherwise would have occurred or been known to you. That being said, no one can ever define all of the failure modes that might occur (which is the primary reason that an FMEA is a living document for the life of the design effort). The bottom line is if an effort is not made to identify as many failure modes as possible, prior to beginning actual design/development, you will doom yourself to numerous iterations of fixing as you go, Art if you will, and you will never come close to have a robust product for the end user.

I have to stand by the statement that, "nothing should ever be treated as an art". I do not agree that there are two extremes with gradients between them. My belief, and this has been born out over many years and over many, many different design projects for immature and mature technologies. Your guidance system is a good example.

To begin with this was much more than a giant calculator containing nothing more than rudimentary code. Among many of the other things the system might be, the code itself would have been considered in their user requirements, their functional requirements and finally in their FMEA. They would have, and most certainly did, attempt to predict everything external to code that might have an effect on it. They would also have made the effort to predict everything within the code that might alter it's performance and outputs. Additionally, they most certainly did this frequently throughout the design/development process. If the Giant Calculator performed as required and provided them with the data/numbers they wanted it was only because they practiced science and not art.

Of course if code is not very complex then less is required and practicing art instead of science might well be practicable and one can easily get where they want to go. However, whether the application is simple or complex I can guarantee that if the developer has a robust Design Control process in place and uses throughout the design process there will be significantly fewer failures in the code that makes up the application.

Tech, What you say is true. Many clients/customers have no idea what they want and are not inclined to even want to think about it. I worked in Pharmaceuticals and medical devices and we had to comply with many entities (ISO being one of them). While I am not at all a fan of GAMP (I hate it), I would suggest that anyone who develops applications and does not already use Design Control take a good long look at it. You will be amazed at how much better your product will be and how much better it will perform over its life cycle.

And guys, whether you prefer art to science or science to art, you have all been very helpful to me and, in this case, have provided me with some very helpful insights of using Try/Catch as a tool to deal with (some) failure modes.

Also, if you are interested and want to discuss this further, I would very much enjoy providing you with information on how you might implement a Design Control process into software design/development. Call it an returned favor for all you guys have done for me.


At the end of the day one must first understand that everything can be defined as a process (including software) and any process can be approached as science. You do not have to do this, but you can.

I still don't understand if there is a question being asked. You seem to understand your own process very well, so that can't be the question.

Actually, there was a question, but mostly this was discussion. The original question was about the cost (in process time) of Try/Catches. That question was indeed answered.

Quote:

---

Originally Posted by gwboolean

...
It is my understanding that the efficiency of the application can be reduced (in terms of an increase in processing time) to use Try/Catches as a remediation tool, which slowly and painfully brought us to the simple and seminal question I have. It is my understanding that using the Try/Catch methods can increase processing time. What I most need to understand about this is that unless the Try fails and the Catch is executed how is processing time increased? It seems to me that processing time should only increase when the Catch is executed. Is this true?

---

Here is a good read on your actual question...

https://www.codeproject.com/Articles...eptions-in-NET

Of the people in this thread, I'd say that we ALL have "years of experience". I may have the least, since I spent the first couple decades of my career as a fish biologist with coding as no more than a sideline.

As I said before: You can spend as long as you wish trying to fight coding into being a science. Lots of people have. Eventually you'll give up, whether through retirement, or recognizing the futility. Perhaps you can write a book about it. I've got a few of those in my office....well, I'm kind of in the back of a storage closet, so 'my office' has to be taken with a certain amount of charity, but the books ARE there. Treatises written decades back advocating what you are trying to push for.

Keep in mind that what you are trying to do is force form over function. You've decided that there should be a Design Control process for software development, and are putting your effort into making the function fit the form you feel must be there.

I agree with Shaggy - it's art. Art - just like making music is art. Just like Einsteins theories - art.

imo...

It also meets with considerably more failure than people tend to realize. Studies on software project failure (as opposed to the program failure, which is due to software bugs) are controversial, since the measure is necessarily subjective, but one extensive survey found that failure was around 70%. They counted failure as wildly over budget, over deadline, or well below expectations. They also reported about 30% cancellation, which is part of the 70%, and is failure by anybodies measure. As for the rest of the failures, though, they could just as easily be a failure of expectation rather than a failure of the project. If a project goes wildly over budget, is that because things went wrong, or because the budget estimate was absurdly low? In any case, what they measured was that a strong majority of project leaders were sufficiently disappointed in the outcome of their projects that they were willing to slag them on a survey.

This is part of where agile comes from. What's the advantage of taking the time to figure out failure states and so on if you're going to be disappointed in the majority of projects and a third of them will never be completed? It would make more sense to spend the analysis time on projects that will be finished, and that's only two in three. So, how do you know which ones will work? You don't. This is where all the "fail fast" comes from. Get something together quickly such that you get an idea whether or not the project is worth investing further in.

Quote:

---

Originally Posted by gwboolean

Oh yeah. I clearly remember how hard it can be to get user requirements. But if you don't get them (one way or another) you will never be able to deliver a product that fully does what is needed or wanted. Frequently the customer will never actually provide you with a useful set of user requirements and it is left to you to figure it out as best you can.

...

Tech, What you say is true. Many clients/customers have no idea what they want and are not inclined to even want to think about it. I worked in Pharmaceuticals and medical devices and we had to comply with many entities (ISO being one of them). While I am not at all a fan of GAMP (I hate it), I would suggest that anyone who develops applications and does not already use Design Control take a good long look at it. You will be amazed at how much better your product will be and how much better it will perform over its life cycle.

...

Also, if you are interested and want to discuss this further, I would very much enjoy providing you with information on how you might implement a Design Control process into software design/development. Call it an returned favor for all you guys have done for me.

---

It's not that I don't get user requirements... It's that I often get the WRONG requirements. I get what they asked for. I get what they wanted. But more often than not, it's not 1)what they meant, or 2) not what they NEED.
I was on a project where they were replacing one system, which happened to be an older product of ours, with one of our newer products... too often I got the repsonse "What ever X did, we want Y to do." Which is stupid. I kept pressing them on that... You want Y to do what X did, is that because that's your process, or is that because that's how X did it? Ended up finding out it was their process because that's how X did it and they didn't know any other way how to do it. This is where part of the art comes in... teasing the information out... there's no magic formula or process that's going to get that for you. Once you do get that info, sure, you can run it trhough your processes, distill it down, and stuff it into your little pigeon hole boxes. And it's going to remain clean, sterile and scientific, right up to the moment the first lick of code is written. That's because coders are artists in a way. Just like painters, we all have our own style. Sure, we conform to some respect when it comes to shop standards, but that's us simply coloring in the lines. We're still going to use Black when someone else will use Blue and red when someone uses green. Some will code a select case when others would use if...then...elseif...elseif...and so on. We use code as our medium.

That's not saying there isn't room for a scientific approach to things... there is, and there should be... but it shouldn't be the be-all, end-all approach when it comes to software development. Conversely, it shouldn't be a completely artistic approach either... it should be a fine balance somewhere between the two, possibly crossing over one way and back again depending on the approach. Debugging and troubleshooting issues should most definitely be done in a controlled, scientific-style approach. But even then, there's a bit of an art to it.

-tg

Quote:

---

Originally Posted by techgnome

...We use code as our medium.

---

Just look back at what the old masters did to make paintings - ones that have survived centuries. Take a piece of wood and carefully apply layers and layers of thick oils and varnishes. Build up a surface most scientifically to then finish it with the perfection of art.

In terms of requirements, I've always favored something I saw in some blog post somewhere. It went something like:

Quote:

---

Users who want tea will come to you asking for matches and a cup of water.

---

Luckily I was born with very strong psychotic abilities so my clients take what I give them and just smile.

Quote:

---

Originally Posted by wes4dbt

Luckily I was born with very strong psychotic abilities so my clients take what I give them and just smile.

---

That's good!!:lol::lol::thumb::afrog:

szlamany,

That was an excellent article. However, there was one part I did not fully understand and that was the cross domain portion. The fact is I am not clear on exactly what is meant by application domains. That is a term I have not run across before. would that be considered the code residing in one class to another or from one project to another or one platform to another? Knowing that would be very important to some ideas I have about how a set of stand alone applications that are designed to be used as a single multi-purpose application might be approached.

Shaggy/Szlamany,

I would beg to defer. My own belief is that the two of you consider code and code processes to be somehow different from any other process. That is just not the case. The fact is, and has long been known, that a process, is a process, is a process. What that means is that all processes have the same concepts and abide by the same rules. The only thing that can be differentiated in different processes is how one might approach one or the other. I will freely admit that the Design process, when applied to software would not even look the same as that I would have used for designing something like a immunoassay.

While I have never actually put together a Design Control for software development, I have seen several that are known to be quite adequate. In fact the only argument that I have with them (GAMP being the worst but a good example) is that those who have put them together do not have a full understanding of the engineering principles required for a truly robust design system. Now, having said all of that I am retired now and do this for a hobby so I feel no need to apply any, or at least most, of the design principles that have been such a big part of my life. But I assure you, whether you choose to believe it or not, that software/application development is as subject to being treated as a science as anything else.

Again, thanks for the article and if you could give me a little more explanation about the domains that could be very useful to me.

Quote:

---

Originally Posted by gwboolean

szlamany,

That was an excellent article. However, there was one part I did not fully understand and that was the cross domain portion. The fact is I am not clear on exactly what is meant by application domains. That is a term I have not run across before. would that be considered the code residing in one class to another or from one project to another or one platform to another? Knowing that would be very important to some ideas I have about how a set of stand alone applications that are designed to be used as a single multi-purpose application might be approached.

---

This link should give you lots of info on AppDomain

https://docs.microsoft.com/en-us/dot...cation-domains

Get to the part titled "Application Domains and Assemblies" - I believe that discusses how you might have a CLASS that is also in a different AppDomain then your main code.

I'm sure JMC and Sitten can elaborate.

Szlamany,

PSHEWWWW! That is the sound of something passing right over my head. Actually, I do get some of it, just barely. But yes, I might need a little more than a little bit of elaboration. Thanks though.

Here is something I believe to be the case - keep in mind this is not my forte as well...

IIS - which is the MS product that runs a web page - runs as a single process. Each web request - which is coming from many, many browsers out in the interweb - needs to run in a "separate" world. The expense of starting a new "application" for each web request is not an option. Running each as a separate "thread" is too close for comfort (as an error in one "app domain" cannot be seen in another "app domain").

Again - this is not my strong suit - I also look forward to some elaboration from the experts!

It might be a surprise, but I won't talk at length about AppDomains, but it is fun to know what they are.

An "Application Domain" is sort of like the world in which an application lives. It has your stack/heap memory and all of those goodies. You can actually create a new AppDomain if you want to. Why would you do that? Well, sometimes you're doing tricky stuff.

Visual Studio does it. The WinForms and WPF designers are run in a separate AppDomain from Visual Studio. Why? Well, they used to crash a lot. In VS 2010 the WPF designer was very unreliable, and when it crashed it usually took Visual Studio with it. It got so bad I was used to opening 2 instances of VS at all times, so when one crashed I could just switch to the 2nd one.

In the next version, MS changed the structure so the designers would run in a separate AppDomain. They weren't much more stable, but now when they crashed, you got a dialog that told you "Sorry" and 10-15 seconds later the designer would start up again. That's much better than the entire app crashing!

Before you get too far down the road designing your "lots of apps collaborating" system, you might want to have a look at the plethora of materials Microsoft has written about Azure. Outside of the VB bubble there's been a ton of research into exactly that kind of app. Early work was (I think) Microsoft's project "Volta", which spawned the Reactive Extensions and the "reactive manifesto". MS did that work because they knew they wanted to sell cloud services but to do so they wanted to have an architecture to sell, too. A lot of devs hear those terms, laugh, and say "that's the stupid hooey C# jockeys are caught up in, you don't need it". Walk past them and keep asking around and you'll get answers like, "Oh yeah, that's how we wrote Netflix. Wouldn't be half as reliable without the concepts!"

But you wouldn't necessarily use AppDomains for that. A "process" is technically an AppDomain, and Docker's sort of revolutionized how services are run. It makes it possible to run multiple instances of the same service on the same machine, each with its own independent version of databases and other dependencies.

That's all a lot of "out there" topics for a lot of people, but there's definitely people making it work out there.

Sitten,

There is no need for anyone to worry that I will be traveling down this path anytime soon. What you have stated certainly does clear up, to a large degree, what I didn't understand. It also cleared up any desire I might have with traveling down that path. I will leave making it work to others. That being the case I do not see there ever being any conditions where I should have to worry about the drag on performance caused by AppDomains. Whew!