Hot answers tagged

8

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information). But often this top-level exception handler would ...


4

From what I have always understood about the C# language, when an object is passed to a method, it is only a copy or instance that actually gets passed. That's where you are getting mixed up. All variables in C# are references to objects. The buffer object in your example lives on the heap, and both the consumer and producer have a reference to that ...


2

Pokemon exceptions ... Ever acceptable? Never say (N)ever, but here goes. A concise conceptualization of exceptions shows why. A try block tells me what situations I choose to not handle Where to try, catch, and after-the-fact handle exceptions is a design issue. Focused try blocks convey the program's concerns. Unreliable connections, undefined ...


1

Your Input Database and your Output Database are each at Layer 1. Layer 2 will contain two Translators, one for each Database at Layer 1, that translates between the particular database objects and a "common" (or "universal") object type. Layer 3, your "application", manipulates the common objects. You could view this as a pipeline bent into a "U" shape.


1

No. Others have noted that you may perhaps want to show users all exceptions in a nice dialog, or save them to a log. These are not terribly bad ideas. But what happens when the exception is a StackOverflowException? An OutOfMemoryException? You may even get a ClrException! In essence, you simply can't catch them all. You can try, and it may even provide ...


1

Yes. At the very least, it's justifiable on the client side for applications that serve non-technical users, provided you're giving the user meaningful instructions. For example, "There was an internal error. Please reload the page." Exceptions should always and only be caught at the point that something meaningful can be done to correct the problem.


1

Catching Exception is usually the wrong thing to do, however there are cases where it is acceptable and the right thing to do. When writing web APIs, you might not want to reveal too much information about exceptions to your clients. You may also have designed into your API an error indicator so that clients can use this to decide what to do next. In this ...


1

The problem is not that you are violating the Open/Closed principle, the problem is that you are violating the Single Responsibility Principle. This is literally a school book example of an SRP problem, or as wikipedia states: As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, ...


1

MEF it. Built into the .NET framework is an often looked over namespace, created primarily for handling plugin support: System.ComponentModel.Composition - also known as MEF. MEF can be applied very effectively for DI, possibly providing exactly what you're looking for. First, you decorate a class with the needed attributes: [Export] // This attribute ...


1

You were right, the three letter codes and excel tables weren't a good method for tracking requirements. I have experimented with other systems and came up with this. I divide the tests into UsesCases and ErrorHandling. This allows me to better focus on what I am testing and I can avoid weird naming conventions so that each test has a pretty clear and ...



Only top voted, non community-wiki answers of a minimum length are eligible