When I enter into debug mode in Access 97, the program will halt on any error, even if that error is occurring after On Error Resume Next.
I have a function that tests if an element key is in a Collection Col using
On Error Resume Next
var = Col.Item(key) 'Here the error is raised, and makes debug mode useless
...
InConnection = Not (Err.Number = 5)
This works well in production, but it makes running the program in debug mode useless.
Is there a way to avoid that the program halts on certain errors in debug mode ?
As far as I could search there is no way to test if a key exist in a collection in Access 97, other than try and catch the error using the above method.
In VBA editor Tools | Options... on tab General activate Break on Unhandled Errors in Error Trapping group to silence OERN sections.
To check key existence in a VBA.Collection w/o error trapping one would need a specially crafted typelib, like the one discussed in this forum thread.
Moreover, such typelib is a prerequisite for practicing the art of writing VBA code with Break on All Errors set -- a small feat in itself :-))
Related
In my local/development environment, the MySQLi query is performing OK. However, when I upload it on my web host environment, I get this error:
Fatal error: Call to a member function bind_param() on a non-object in...
Here is the code:
global $mysqli;
$stmt = $mysqli->prepare("SELECT id, description FROM tbl_page_answer_category WHERE cur_own_id = ?");
$stmt->bind_param('i', $cur_id);
$stmt->execute();
$stmt->bind_result($uid, $desc);
To check my query, I tried to execute the query via control panel phpMyAdmin and the result is OK.
TL;DR
Always have mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); in your mysqli connection code and always check the PHP errors.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your MySQLi code produces an error like mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given..., Call to a member function bind_param()... or similar. Or even without any error, but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. In the older PHP versions such errors weren't transferred to PHP, and all you'd get is a cryptic error message mentioned above. Hence it is very important to configure PHP and MySQLi to report MySQL errors to you. And once you get the error message, fixing it will be a piece of cake.
How to get the error message in MySQLi
First of all, always have this line before MySQLi connect in all your environments:
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
After that, all MySQL errors will be transferred into PHP exceptions. An uncaught exception, in turn, makes a PHP fatal error. Thus, in case of a MySQL error, you'll get a conventional PHP error. That will instantly make you aware of the error cause. And the stack trace will lead you to the exact spot where the error occurred.
How to get the error message from PHP
Here is a gist of my article on PHP error reporting:
Reporting errors on a development and live servers must be different. On the development server it is convenient to have errors shown on-screen, but on a live server error messages must be logged instead, so you could find them in the error log later.
Therefore, you must set corresponding configuration options to the following values:
On a development server
error_reporting should be set to E_ALL value;
log_errors should be set to 1 (it is convenient to have logs on a development PC too)
display_errors should be set to 1
On a production server
error_reporting should be set to E_ALL value;
log_errors should be set to 1
display_errors should be set to 0
After that, when MySQL query fails, you will get a PHP error that explains the reason. On a live server, in order to get the error message, you'll have to check the error log.
In case of AJAX call, on a dev server open DevTools (F12), then Network tab. Then initiate the request which result you want to see, and it will appear in the Network tab. Click on it and then the Response tab. There you will see the exact output. On a live server check the error log.
How to actually use it
Just remove any code that checks for the error manually, all those or die(), if ($result), try..catch and such. Simply write your database interaction code right away:
$stmt = $this->con->prepare("INSERT INTO table(name, quantity) VALUES (?,?)");
$stmt->bind_param("si", $name, $quantity);
$stmt->execute();
Again, without any conditions around. If an error occurs, it will be treated like any other error in your code. For example, on a development PC it will just appear on-screen, while on a live site it will be logged for the programmer, whereas for the user's convenience you could use an error handler (but that's a different story which is off topic for MySQLi, but you may read about it in the article linked above).
What to do with the error message you get
First of all you have to locate the problem query. The error message contains the file name and the line number of the exact spot where the error occurred. For the simple code that's enough, but if your code is using functions or classes you may need to follow the stack trace to locate the problem query.
After getting the error message, you have to read and comprehend it. It sounds too obvious if not condescending, but learners often overlook the fact that the error message is not just an alarm signal, but it actually contains a detailed explanation of the problem. And all you need is to read the error message and fix the issue.
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, and letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
If you don't understand the error message, try to google it. And when browsing the results, stick to answers that explain the error rather than bluntly give the solution. A solution may not work in your particular case, but the explanation will help you to understand the problem and make you able to fix the issue by yourself.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. The same goes for the absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advise extremely useful.
A list of things you should never ever do in regard of error reporting
Never use an error suppression operator (#)! It makes a programmer unable read the error message and therefore unable to fix the error
Do not use die() or echo or any other function to print the error message on the screen unconditionally. PHP can report errors by itself and do it the right way depends on the environment - so just leave it for PHP.
Do not add a condition to test the query result manually (like if($result)). With error exceptions enabled such condition will just be useless.
Do not use the try..catch operator for echoing the error message. This operator should be used to perform some error handling, like a transaction rollback. But never use it just to report errors - as we learned above, PHP can already do it, the right way.
P.S.
Sometimes there is no error, but no results either. Then it means, there is no data in the database to match your criteria. In this case you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again.
I've got an article that can help in this matter, How to debug database interactions. Although it is written for PDO, the principle is the same. Just follow those instructions step by step and either have your problem solved or have an answerable question for Stack Overflow.
I have a shiny app that runs a monte carlo simulation with 500 replications. To do this, I use a for loop and call a function from another package to run the simulation, and then I save the data. The shiny app then produces the results using renderTable.
It is possible that the user could mistakenly enter something that would cause one or more of the replications to fail to converge, triggering a stop in the function I'm calling. If this happens, there is nothing to render in a table. In R, I get a nice error message from the package telling me that the model failed to converge. However, in Shiny, the app just force closes.
I'm currently using tryCatch and showNotification to display this notification in the app (see below):
observeEvent(input$go,
tryCatch({
simulation_results()
},
error = function(err){
showNotification(paste0(err), type = 'err')
})
)
It works well, but the problem is that it causes the app to take 6x longer to run (it goes from ~1.5 min to ~10 min). I think this is because it's trying to catch and show the notification from every individual replication in the for loop. The app also still does close; it just displays the error first (which I do appreciate).
Is there a [faster] way to get shiny to print error messages from the console instead of closing the app?
I was thinking of validate, but I don't know how it would work - what I really need is something like
validate(need("no error message in the console")). I tried using validate(need(simulation_results(),geterrmessage()) to see if it would simply print the last error message if there were no simulation results, but the app shuts down once it gets to the stop error in the function.
Also, I'm using flexdashboard if that changes anything.
I am using Matlab's Image Acquisition Toolbox to acquire high-speed video over gigabit Ethernet. I'm having some trouble with frame-dropping, but that's not what this question is about. What I really want to do is tell Matlab to continue running the script even after encountering the frame-dropping error.
I used a try/catch statement for this purpose but it just doesn't work. Here is my code, sparing some of the details relating to setting up the camera and using the data:
%% setting up camera
while(1)
% continue acquiring data forever
while(vidObj.FramesAvailable < vidObj.FramesPerTrigger)
% wait until we're ready to get the data
try
pause(.1)
catch exception
disp "i got an error"
end
end
% get the data
[img, t] = getdata(vidObj);
%% do something with the data
%% ...
end
What happens is that, every once in a while, some frames are dropped and the toolbox raises an error. This happens inside the try block, but Matlab raises an exception anyway! The output looks something like:
Error event occurred at 21:08:20 for video input object: Mono8-gige-1.
gige: Block/frame 1231 is being dropped beecause a lost packet is unable to be resent....
Error in script_name (line 82)
pause(.1)
You can see that the error occurs while we're waiting to collect data (the "pause" statement), which is inside the try block, and yet the exception is not caught correctly because my debugging message doesn't print and the program grinds to a halt.
How can I get Matlab to observe the try/catch structure and continue after this error happens?
I figured it out. The error message is not a true error, but more of a warning. Execution does not stop. However, vidObj stops collecting frames and my code keeps looping forever, waiting for enough frames to be collected.
You can insert a check for this condition like so:
% wait until enough frames are available
while(vidObj.FramesAvailable < vidObj.FramesPerTrigger)
pause(.1)
if strcmp(vidObj.Running, 'off')
% It has stopped running, probably because frames were dropped
start(vidObj)
end
end
Now, upon frame dropping, the object will be restarted and acquistion continues. Obviously the dropped frames cannot be recovered so there will be a gap in the video.
I am using ssis event handler to trigger an email whenever an error occured in the entire package(PACKAGE+ONEEROR). Here number of emails triggered is equal to number of errors generated.How can I restrict it to one mail eventhough the same error occured 10 times.
Please suggest....
You have a few options. The problem with setting an ONERROR email at the package level is that it will send an email for each error the package encounters. This gets ugly if you have a deep level transform fail, which will error as it fails back up to the package level.
I suggest that you either:
1) Setup ONERROR events at the task level and remove the package level event. Usually this will be good enough. Most tasks will only have one error to report. Be careful with Data Flows, they can act in a similar fashion as the package level events.
2) Setup some sort of advance logging. I’ve seen this done several ways. I’ve seen some people setup Script tasks to log the errors (at the task level) to a variable, and then send a final email containing the variable in the body (at control flow level). I have also seen people call stored procedures (at the task level and package level) for each error that occurs. The sproc would log errors to the DB and allow the package to continue on to the next step/container. The logged errors can then be dumped into a csv and emailed as an attachment.
If you like your current setup, you can try changing the error properties for each container/task. I haven't ever done this, but I do know you can change the way tasks handle errors! I don't like this option because you would possibly be missing errors (maybe? kind of guessing).
update From another solution - If you want to keep your current email ONERROR and simply prevent certain errors from "bubbling" up and sending emails, you can follow this link to learn how to gracefully handle errors. You could prevent certain tasks errors from reaching your ONERROR event at the package level. good luck.
I'm trying to debug an issue on a clients machine. The problem is that the problem is a runtime error with very little clue as to where it is. It is an intermittent problem. I know ADL allows me to run the application in a debug mode. The problem is that to tell the user to download and manage the ADL invokation is going to be very difficult. It would be a lot easier if I could just give the end user one install/executable to install and run and then send me the trace of the issue. So what I'm looking for is easy steps for the client to be able to run the AIR app in debug mode. Downloading ADL and finding the install location of the app is going to be difficult to manage remotely with the end user.
Update:
You have to make sure you are working with AIR 3.5 and Flash 11.5 and also include the following flag "-swf-version=18" in additional compiler settings. You then have to catch the global error as mentioned in the answer and it will show you the location of the error. No line numbers of course. Just routine names. Thanks a milion to Lee for the awsome answer.
not a direct answer but if you publish for AIR3.5 (or 3.6 beta), you can get some debug info:
add a listener for uncaught RTEs to top level of your app:
this.loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, globalErrorHandler);
and grab debug info from error in listener:
function globalErrorHandler(event:UncaughtErrorEvent):void
{
var message:String;
//check for runtime error
if (event.error is Error)
message = (event.error as Error).getStackTrace();
//handle other errors
else if (event.error is ErrorEvent)
message = (event.error as ErrorEvent).text;
else
message = event.error.toString();
//do something with message (eg display it in textfield)
myTextfield.text = message;
}
getStackTrace will return a stack trace even for release AIR apps (as long as you use AIR3.5 or above).
Without the SDK Tools; I don't think it is possible to run an aIR app in debug mode. But, here are a few alternatives to consider:
The client must have some idea what is going on to cause the error, right? Can you give them a special build with Alert Boxes or logging or something to help isolate the error to a line of code?
Can you listen for the uncaughtException event? The event will give you the full stack trace ( Error.getStackTrace() ); which you could then log--possibly with other information. Then you just have to tell your client to "Go here" and "send me this file." Or even display the info in some Alert and have the user copy and paste it into an email to you. More info on uncaughtException here and here
check my post. Maybe it helps you to get stack trace with line numbers in a AIR release build.
How can I get stacktrace for Adobe AIR global runtime errors in non-debug mode?
I use it in 2 big projects right now and it works very well.
Greetings