I just read this question, and a solution states that:
The fact that you don't know you got
the NO_DATA_FOUND exception suggests
that you have made one of the biggest
errors PL/SQL developers ever make:
EXCEPTION
-- Never do this in real code!!!
WHEN OTHERS THEN NULL;
END;
Could you explain me what is the error in this statement and what would you do to avoid doing that...
The problem is, that you are catching all exceptions, and then ignoring them. You'll never know when something went wrong.
There's nothing wrong with this snippet of code if you don't want the pl/sql block's exception to propagate any further for example. If you do it on purpose, it's not bad code or a mistake. That's the catch all in pl/sql. And there might be situations in code where you have nested BEGIN/EXCEPTION/END blocks and one might not want the transaction to fail just if a particular cross section of code fails. You can't state it's bad coding if you do it intentionally for whatever reason/requirement.
BEGIN
--something important here
--something even more important here
BEGIN
--something secondary goes here but not important enough to stop the process or
--log a message about it either
--maybe send an informative email to the support group or
--insert a log message when debugging the process or
--the list could go on and on here
EXCEPTION
--I don't care if this block fails, absorbing all errors regardless of type
WHEN OTHERS THEN NULL;
END;
-- something super important here, must happen
EXCEPTION
WHEN NO_DATA_FOUND THEN
-- do something useful for this exception
WHEN OTHERS THEN
-- do something by default if we don't expect this error
END;
It is ALWAYS bad coding. And you can say that it is bad coding if you do it on purpose. In fact, it is horrible code if you do it on purpose because it demonstrats how little you understand about all of the errors you are completely ignoring.
http://stevenfeuersteinonplsql.blogspot.com/2017/02/now-not-to-handle-exceptions.html
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1155066278457
Related
Is there a Goto statement in Halcon? I was not able to find it in the documentation. What I would need is to jump back about 50 lines of code in a certain condition.. Since it happens rarely I'd like to avoid doing it with a loop. Is there a goto statement or something similar that allows me to jump back to a previous point in the same procedure?
No there is not the GOTO statement.
The reason can be: "Code that relies on goto statements is generally harder to understand and to maintain than code without gotos. Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all." (Brian Kernighan & Dennis Ritchie, The C Programming Language)
https://en.wikipedia.org/wiki/Goto
i know its by design, in finally block i should do resource cleanup - that's why the finally block is always executed no matter what the exception handling code is.
But "WHY" it will execute is my question?, this was asked to my friend in an interview, so even i got confused after discussing with him, please clarify, thanks in advance.?
"WHY" here could be summarised as "because that is what the specification says; that is why it was designed, specified, implemented, tested, and supported: because they wanted something that would always execute, no matter what the exception handling code is". It is a bit like asking "WHY does execution flow to the else block (if one) if the condition in an if test fails?"
The uses of finally include:
resource cleanup (Dispose() being an important one, but not the only one)
logging / tracing / profiling the fact that we finished (whether successful or not)
making the state consistent again (for example, resetting an isRunning flag)
Anecdotally, I make much more use of finally than I do catch. It is pretty common that I want something to happen while leaving, but often with exceptions the best thing to do is to let them bubble upwards. The only thing I usually need to be sure to do during an exception is to clean up any mess I made - which I need to do either way - so I might as well do that using a combination of finally and using (which is really just a wrapper around finally anyway).
It's almost always around resource cleanup - or sometimes logical cleanup of getting back to a reasonable state.
If I open a file handle or a database connection (or whatever) then when I leave that piece of code I want the handle to be closed regardless of how I leave it - whether it's "normally" or via an exception.
finally blocks are simply there to give that "Execute this no matter what1" behaviour which can often be useful.
1 Well, within reason. Not if the process dies abruptly, for example - of if the power cable is kicked out.
With PL/SQL will there ever be a situation, say in the case of an exception, where an implicit cursor will fail to close?
I understand that an implicit cursor is supposed to close itself after use, but just want to know if there's ever a situation where this might not be the case, and if this is possible, what kind of remediation will be a good idea.
When COMMIT or ROLLBACK fails the cursor will not close automatically
It is recommended to use route bellow when using cursors:
-- before using the cursor
IF your_cursor %ISOPEN THEN
CLOSE your_cursor;
END IF;
OPEN your_cursor;
-- after using the cursor
CLOSE your_cursor;
-- when exception
IF your_cursor %ISOPEN THEN
CLOSE your_cursor;
END IF;
I'm going to assume that you're talking about implicit cursors, i.e. a SELECT INTO... or a DML statement executed within a PL/SQL block as opposed to a FOR loop.
As with explicit cursors implicit cursors have attributes; you can use SQL%NOTFOUND (instead of CURSOR_NAME%NOTFOUND for instance.
To quote from the 11.1 documentation on implicit cursor attributes for SQL%ISOPEN:
Always returns FALSE, because the database closes the SQL cursor
automatically after executing its associated SQL statement.
This should, I believe, be taken to mean that the cursors will be closed after execution, whether an exception is raised or not. After all, an execution halted due to an exception is still a executed SQL statement.
The reason has been removed from the 11.2 documentation.
SQL%ISOPEN always has the value FALSE.
It appears to have been added to the chapter on implicit cursors instead:
SQL%ISOPEN always returns FALSE, because an implicit cursor always
closes after its associated statement runs.
Whether the cursor closes or not doesn't really matter due to the answer to your final question, "what kind of remediation will be a good idea.". To quote from the same chapter:
You cannot control an implicit cursor, but you can get information
from its attributes.
So, no. There's no remediation possible; it is impossible to explicitly close an implicitly opened cursor.
The one thing you might want to test is whether you can raise ORA-0100: Maximum open cursors exceeded using solely implicit cursors as this is the worst consequence I can think of.
Let's define an "implicit cursor" as a SELECT statement executed in a FOR loop.
Looking at it from a practical point of view - regardless of whether or not it's possible for an implicit cursor to be left open, the important question is "What can you do about it?". To the best of my knowledge, the answer to that question is "Nothing". You don't have a cursor variable to work with, there's no way (that I know of) to access the implicit cursor, and thus you really can't affect it.
There's two things you can do. The first is to completely avoid the use of implicit cursors. Only use explicit cursors, go through all the steps of opening, fetching, closing, etc. This gives you the maximum level of control. If you're into this sort of thing, go for it.
On the other hand, you can use implicit cursors and just not worry. I'm good with not worrying. :-) Seriously, though, implicit cursors are IMO hugely better than explicit cursors. There's less code to write, and therefore less code to screw up. The system can, in certain circumstances, optimize the use of implicit cursors without requiring you to write a pile of extra code. The code you write is cleaner and more easily understood - not a concern if you're working in a one man shop where you write and maintain all the code, but out here in Corporateville we often have to write code others will maintain and vice versa, and it's considered polite to hand over the cleanest, clearest code we possibly can. There are times (such as when handing a cursor variable back to a caller from outside of Oracle) when explicit cursors are necessary, but for most code I'm using implicit FOR-LOOP cursors - and LOVING it! (And extra bonus points for those who can recall where that comes from :-)
Share and enjoy.
I was developing a website by using c# with .net framework 4. OO concepts have been implemented. Each layer has some Try Catch blocks used to handle different errors and return different error messages. I found that it getting slower when loading as the try catch block getting more and more. I wonder this is because why. Any alternative solution? Correct me if I am wrong. Appreciate for any reply.
There is nothing wrong with using try/catch blocks. They don't alter performance. what does alter performance is throwing errors!
see web site below particularly:
Throwing exceptions can be very expensive, so make sure that you don't
throw a lot of them. Use Perfmon to see how many exceptions your
application is throwing. It may surprise you to find that certain
areas of your application throw more exceptions than you expected. For
better granularity, you can also check the exception number
programmatically by using Performance Counters.
http://msdn.microsoft.com/en-us/library/ms973839.aspx
Exception usually help us to handle the wrong initialization (creating the object with an invalid state) of an object because the constructor doesn't return any value or in the other case if we have an method which return an instance of an object which should never be null. So in case of constructor you could create an static method named getInstance which will return you the instance of your object or null in case of wrong initialization, make your constructors private in this case but exceptions are much better. In case of method which return an instance you could use the technique that COM technology use, by passing an reference to your boolean variable which will show you the execution result.
There are some good links about try/catch and their cost. Microsoft says that it can negatively affect performance.
I would review whether you are using exceptions for what they are really for, exceptional circumstances, and not for program flow. If they do affect program flow, then you're risking the possibility of side effects. MSDN states:
Clean up intermediate results when throwing an exception. Callers
should be able assume that there are no side effects when an exception
is thrown from a method
If this is the case, then I would consider creating methods which return errors explicitly as/when necessary and handle this way instead.
i am creating a system. What i want to know is if a msg is unsupported what should it do? should i throw saying unsupported msg? should i return 0 or -1? or should i set an errno (base->errno_). Some messages i wouldnt care if there was an error (such as setBorderColour). Others i would (addText or perhaps save if i create a save cmd).
I want to know what the best method is for 1) coding quickly 2) debugging 3) extending and maintenance. I may make debugging 3rd, its hard to debug ATM but thats bc there is a lot of missing code which i didnt fill in. Actual bugs arent hard to correct. Whats the best way to let the user know there is an error?
The system works something like this but not exactly the same. This is C style and mycode has a bunch of inline functions that wrap settext(const char*text){ to msg(this, esettext, text)
Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);
Generally if it's C++, prefer exceptions unless performance is critical or unless you may be running in an environment (e.g. an embedded platform) that does not support exceptions. Exceptions are by far the best choice for debugging because they are very noticeable when they occur and are ignored. Further, exceptions are self-documenting. They have their own type name and usually a contained message that explains the error. Return codes and errno require separate code definitions and some kind of out-of-band way of communicating what the codes mean in any given context (e.g. man pages, comments).
For coding quickly, return codes are probably easier since they don't involve potentially defining your own exception types, and often the error checking code is not as verbose as with exceptions. But of course the big risk is that it is much easier to silently ignore error return codes, leading to problems that may not be noticed until well after they occur, making debugging and maintenance a nightmare.
Try to avoid ever using errno, since it's very error-prone itself. It's a global, so you never know who is resetting it, and it is most definitively not thread safe.
Edit: I just realized you meant an errno member variable and not the C-style errno. That's better in that it's not global, but you still need additional constructs to make it thread safe (if your app is multi-threaded), and it retains all the problems of a return code.
Returning an error code requires discipline because the error code must be explicitly checked and then passed up. We wrote a large C-based system that used this approach and it took a while to remove all the "lost" errors. We eventually developed some techniques to catch this problem (such as storing the error code in a thread-global location and checking at the top level to see that the returned error code matched the saved error code).
Exception handling is easier to code quickly because if you're writing code and you're not sure how to handle the error, you can just let it propagate upwards (assuming you're not using Java where you have to deal with checked exceptions). It's better for debugging because you can get a stack trace of where the exception occurred (and because you can build in top level exception handlers to catch problems that should have been caught elsewhere). It's better for maintaining because if you've done things right, you'll be notified of problem faster.
However, there are some design issues with exception handling, and if you get it wrong, you'll be worse off. In short, if you're writing code that you don't know how to handle an exception, you should let it propagate up. Too many coders trap errors just to convert the exception and then rethrow it, resulting in spaghetti exception code that sometimes loses information about the original cause of the problem. This assumes that you have exception handlers at the top level (entry points).
Personally when it comes to output graphics, I feel a silent fail is fine. It just makes your picture wrong.
Graphical errors are super easy to spot anyways.
Personally, I would add an errno to your Base struct if it is pure 'C'. If this is C++ I'd throw an exception.
It depends on how 'fatal' these errors are. Does the user really need to see the error, or is it for other developers edification?
For maintainability you need to clearly document the errors that can occur and include clear examples of error handling.