New answers tagged exceptions
0
Should I check passedValue and throw an exception in:
The Web Service
The Service
The Repository
What are you going to do if the string is null? Throw an illegal argument exception to prevent a null pointer exception?
I would not check unless failure to do so could lead to a security hole. A null pointer exception followed by a 404 or ...
0
Personally, it depends on what is going on in the methods. If the middle method is just passing it down, then I wouldn't check there. The method that needs to validate the parameter does the check. Even if the parameter is checked upstream, the method that needs a valid parameter should check.
0
In my opinion, it depends greatly on how the code is going to be used. If the code (classes, etc.) you are creating will be reused in multiple different ways -- or by other people -- then you might want to have multiple levels of checking (as appropriate -- it may be OK to just let a null reference exception happen). But if it's more likely to be kept to a ...
0
If passedValue is used in either MyWebServiceMethod or MyServiceMethod in any way aside from calling MyServiceMethod and MyRepositoryMethod then you'll need to check it in those places so that whatever code in each of those layers that consumes passedValue has a valid value to work with.
If, on the other hand, at each layer passedValue is only used to call ...
1
As long as a "layer" expose a public interface with a contract, the null value should be checked. So in your case you should have 3 null checks.
This will allow you to be fool proof if MyServiceMethod or MyRepositoryMethod are invoked from somewhere else.
3
If null is not valid on the web service, then check it in the web service.
If it ever becomes valid, update the code. Don't worry about implementing things that do not currently exist and you don't know if they ever will exist.
You already know that null is invalid, so catch it immediately.
If there's only one parameter and null becomes valid you may ...
0
2 solutions :
- null is or may become a valid value for your service. In that case you have to pass it along your stack.
- If null value is forbidden, the basic validation is better at the upper level (webservice) to avoid unnecessary calls.
0
There isn't one answer here -- kind of like there isn't one sort of HttpException.
It makes alot of sense that the underlying HTTP libraries throw an exception when they get a 4xx or 5xx response; last time I looked at the HTTP specifications those were errors.
As for throwing that exception -- or wrapping it and rethrowing -- I think that really is a ...
0
I used a combination of both solutions: for each validation function, I pass a record that I fill with the validation status (an error code). At the end of the function, if a validation error exists, I throw an exception, this way I do not throw an exception for each field, but only once.
I also took advantage that throwing an exception will stop execution ...
4
Others have discussed RAII as the solution. It's a perfectly good solution. But that doesn't really address why they didn't add finally as well since it's a widely desired thing. The answer to that is more fundamental to the design and development of C++: throughout the development of C++ those involved have strongly resisted the introduction of design ...
2
You can use a "trap" pattern - even if you don't want to use try/catch block.
Put a simple object in the required scope. In this object's destructor put your "finaly" logic. No matter what, when the stack is unwound, object's destructor will be called and you'll get your candy.
22
As some additional commentary on @Nemanja's answer (which, since it quotes Stroustrup, is really about as good of an answer as you can get):
It's really just a matter of understanding the philosophy and idioms of C++. Take your example of an operation that opens a database connection on a persistent class and has to make sure that it closes that connection ...
14
The reason that C++ does not have finally is because it is not needed in C++.
finally is used to execute some code regardless of whether an exception has occurred or not, which almost always is some kind of cleanup code. In C++, this cleanup code should be in the destructor of the relevant class and the destructor will always be called, just like a finally ...
21
From Why doesn't C++ provide a "finally" construct? in Bjarne Stroustrup's C++ Style and Technique FAQ:
Because C++ supports an alternative that is almost always better: The "resource acquisition is initialization" technique (TC++PL3 section 14.4). The basic idea is to represent a resource by a local object, so that the local object's destructor will ...
1
a) In code we implement preconditions and postconditions either as assertions or as exceptions?
Strictly, no. The pre/postcondition is actually the test that raises the exception. The exception is merely the way of saying that pre/postcontion has been violated.
b) We implement preconditions and postconditions in code as exceptions if not ...
0
You should define them as assumptions, (in debugging as assertions) so if the pre or post condition isn't true then you have an logical error in in your program.
The key point here is avoiding the test in production code to speed it up,
for example a binary search can go in O(log n) time only if the array is already sorted (precondition) but testing this ...
Top 50 recent answers are included
