Tag Info

New answers tagged

2

If a function is declared as nothrow throws an exception anyway, that is a bug pure and simple. Given that, to ensure your destructors don't throw any exceptions, there are two paths: Only call functions that are known not to throw an exception (either because they are declared with nothrow, they are documented not to throw, or they are implemented in a ...


1

On the conventional wisdom that states that you should only throw an exception when a condition occurs that you can't handle in your code we tend to focus on the definition of an exceptional condition but ignore the definition of what it means to handle the exception. A process may encounter a exception communicating with a particular node and may handle the ...


3

You seem to have some misunderstandings about exceptions, so let's try and clear those up first. Throw an exception when some condition occurs that you can't handle in your code. For example, if your code is supposed to open a file and do something with that file, but the user supplies a path to a file that does not exist, then you should throw an ...


2

There are some great answers here, but I think one important reason has not been emphasized enough: When exceptions occur, objects can be left in invalid states. If you can "catch" an exception, then your exception handler code will be able to access and work with those invalid objects. That is going to go horribly wrongly unless the code for those objects ...


0

So here, you're writing the handler that throws the exception and the grid manages that exception itself. I see this as fair enough - after all, you're writing the library code that throws on error states, and the caller (ie the grid) catches and manages the exception how it likes, in this case showing a message to the user in a dialog (which is perfectly ...


2

Since the .NET framework standard UI controls do not catch unhandled exceptions by themselves, and offer you some mechanisms to catch those exceptions in a central place, I agree that it is questionable why a 3rd party control should behave differently. Lets assume, from the nature of your application, in case of a severe failure, you are 100% sure you can ...


1

I am very fond of hard error & fail fast, I believe they are the one true and right way to go, but I try not to be dogmatic about them. There are cases where the best thing to do with an unexpected exception is to log it and swallow it. I will give you an example which is more simple than your situation: suppose you have an observable collection which, ...


1

I recently solved a similar problem with a third-party library. Allow me to restate to make sure I'm not misinterpreting your situation. You know how to work around it, but you don't like the repetition of the workaround, and you feel it obscures your actual code? I solved my problem using a python decorator that catches an exception and handles it ...


2

What is there to do. In my view, the decision to turn an exception during validation into a failed validation is a correct way of handling such exceptions. Letting the exception pass through and crash the application has a significant risk that you lose the work the user had been doing, even if the situation was caused by bad user-input and entirely ...


0

The technique I use is to combine, and outsource the validation and throwing altogether to a utility function. The single most important benefit is that it is reduced down to a one-liner in the business logic. I bet you can't do better unless you can reduce it further - to eliminate all argument validations and object-state guards from the business logic, ...


0

Don't get me wrong, i like lambdas, but how is that "MVP"s code better than this: private void Search() { try { var info = _DataService.GetByACNo(_model.AccountNumber); if (info != null) { _Model = info ; this.SetViewPropertiesFromModel(_Model, _View); } else { ...


1

For the public SDK scenario, I would strongly consider using Microsoft Code Contracts as these provide informative errors, static checks and you can also generate documentation to add into XML docs and Sandcastle generated help files. It is supported in all paid for versions of Visual Studio. An additional advantage is that if your customers are using C#, ...


4

If the system 2 handles the exception and doesn't rethrow it, then it sounds like system 1 doesn't have any way of knowing that an exception occurred. In that case, there's really no question as to whether system 1 should log anything, since it doesn't know an error occurred! If both systems are aware of the error, and they are logging to different places, ...


0

It depends on the exception. If you expect that the exception may occur and it is valid, and you are actually handling it, as in, you've got plan B for that situation, then don't throw it. If the exception breaks the workflow and you aren't actually handling it, go ahead and log it if you deem it necessary, but sometimes the current method scope doesn't ...


1

You could argue that they should both log it. System 1 is trying to accomplish something but needs to access System 2. System 1 should log that it couldn't successfully complete its work for some reason or another due to its dependency on System 2. If System 2 encounters an internal error processing a request, it should be logging those types of issues ...



Top 50 recent answers are included