As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Is Exception Handling about transferring control from the called routine to the calling routine or is it about throwing messages?
I believe the correct answer to this question is "yes" -- it allows you to send a message back to the caller that says "I've encountered an error/exceptional condition; you may now do something about it".
Exception handling is about handling exceptions.
It's useful if you want your program to crash gracefully, or If your program does many things and you don't want it to grind to a halt because one non-critical operation failed.
You generally want to log or display your exceptions in some way, so you at least have a stack trace when your program fails.
Exception handling is a generic term which is pretty self explanatory. It describes any code used to handle unusual circumstances AKA "exceptions" that may occur during operation.
As for your transferring control or throwing messages question that depends entirely on the language. Not all languages allow throwing of exceptions so that part just depends on which technologies you're using.
Exception Handling is about capturing errors that produce exceptions and reacting appropriately.
Throwing an exception is a technique that allows both information about an exception and responsibility for handling it back to the calling function. It is saying something happened in the function that could not be recovered from while still completing the expected operations of the function.
An exception may be handled within a function by throwing an exception, so they can also be combined.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the best practice when you're dealing with exceptions?
I usually write code to avoid exceptions at any cost, my code usually has a lot of conditions and if I'm dealing with normalized databases, I usually write a bunch of queries that double check if the values are already there.
However, I've seen code that just listens for exceptions, and if an exception occurs then it is handled appropriately.
What are the best practices in this scenario?
Is it better to avoid errors and handle them before they happen, or just catch the exception and channel it to the right place?
In terms of performance, I've seen that it's faster to catch the exceptions; especially if there's a database involved.
However, I feel that some exceptions are too general for specific scenarios and it's hard to determine why that exception occured unless you see the stack trace.
That said, unless you have a error reporting tool in place (rollbar, new relic, etc..) is especially hard to find the stack trace in the logs if you have customer facing interfaces and you receive tickets that only contain the words "500 error in X page".
If this question is too broad for stackoverflow feel free to close it
If there is concurrent updates happening in your database and your database access methods of checking and writing is not in one transaction you must anyway implement exception handling. So I would say that you might be better off just implementing a thorough and stable exception handling. But to answer this in general is very hard, because it always depends on the circumstances.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm a beginner with TDD; I've just read TDD by example and now I can't seem to stop writing code in a TDD fashion. I've noticed that a lot of the time I'm writing a test, see it fail, correct it, and refactor. And then after some tests I see that there was actually a better way to write the interface all-along which leads me to want to change some of the previous tests.
It obviously makes a lot of code I write a waste of time, so I'm wondering if it is a good practice to write all of the tests at once (or at least try to) in-order to save time? I'm asking because I know it's not the standard way, but is it wrong?
The real question is "Do you get more finished code done in a given length of time?" It doesn't matter how many times you write it and throw it away if you get more in the end.
As you use tests more, you will get better about figuring out whether a test is good or not. Ask yourself the question, "Does this test help the code somehow?" Does it document how to use the code? Does it check that the code didn't get modified incorrectly when refactoring? Does it test the code works right on the "happy path" and for the kinds of failures that are common?
I would write one test and then one bit of code. You have to decide how much is "one unit" of code but you'll get a feel for it as you do it.
Then I would either update the test to make it better and improve the code to meet those changes OR write another test and update the code to meet that tests requirments.
And just keep on going. One bit of test. One bit of code. It keeps you focused that way.
Don't forget YAGNI. (You ain't gonna need it.) This is the principle that says you write code only for what you need right NOW. Don't write any code for "just in case" or "it's needed later."
Later will come with its own requirements. You will still know how to code it, maybe better because you will have more experience. What you think you will need may (or may not) be what you actually need when you get there.
Writing code too early is a waste of time and effort.
"The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow."
Fred Brooks, The Mythical Man-Month
You're not the only one to come up with better ways to do things after they're done. You should actually plan for it. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm developing a new application and i want to test if it's vulnerable. I know some common attacks, but maybe you can provide some more to make my app safer.
Thanks!
Check out this post: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
Also there's a Firefox add-on named SQL Inject Me but right now it doesn't work with Firefox 6
There's no reason to test for multiple attack vectors. Simply passing the character used to quote strings (usually,') should cause a syntax error if its open to SQL injection -- unless you have an IDS or some signature-based detection standing in your way.
Always escape your variables with the proper function (for example, $pdo->quote() or mysql_real_escape_string(), depending on which extension you are using)
Use prepared statements as much as possible
Never escape your variables too early, or you will never know whether they are escaped or not. Just escape them the most lately possible, and always consider that they are not escaped.
Properly set the connection encoding
If you follow this you are not vulnerable to SQL injection (provided that you don't forget to escape something).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I need to evaluate and dig more into the use of Remote Procedure Call Protocols (over the network) and haven't found a comprehensive list of which I could include.
There are some I already know from experience like
RMI
"RESTful style RPCs"
XML-RPC
SOAP
JSON-RPC
(CORBA ?)
GWT-RPC and other Vendor specific ones, commonly used
But I'm still not sure if I am missing some important ones. I want to keep the evaluation as objective as possible so I just need some input on which I might have forgotten and maybe when and for what it is mainly used.
Hessian
Burlap
DCE RPC
Sun/ONC RPC
OSI ROSE
Rabbit MQ
Websphere MQ
Spread
PYRO
There are quite a few more but that should show you some of the diversity. Yes, CORBA is an RPC protocol from before the web. To find out more you should be able to Google on any of the RPC names people have given you, along with the word RPC.
Google Protocol Buffers
BERT-RPC
Thrift as well.
Versile Platform
Internet Communications Engine
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is it a best practice to validate JSON?
With both a JSON schema proposal and a JavaScript implementation of a JSON Schema validator, this practice would seem relatively frictionless to implement. So, is it a no-brainer that should be part of any robust application? Or do you employ other preferred strategies to handle bad JSON?
On the server, validation of data coming from outside is a must.
In the browser, it is redundant from a security POV, if you can vouch that the JSON is generated by server code you control and that any data it depends on has been validated on the server. Even so it can still be useful for debugging.
My 2c on this is that:
(a) Yes, obviously incoming data should be validated, but
(b) The best place to do this is NOT with Json data as is, but with actual business logic objects, iff data binding is used. JSON validation makes only sense if you handle "raw" JSON, but most services (at least in Java) use data binding first and then operate on biz logic objects, not on data format (which often is almost an implementation detail)