Without going into too many specifics, here is the problem.
I have a Drupal 7 site which includes an Ajax-called API that works something like this:
function myApi() {
// get data passed
try {
vendorFunctionCallUsingData();
} catch (Exception $e) {
// send error message back to user
}
// send success message back to user
}
...and it works perfectly. If the third-party code finds a problem with the data, it throws an exception, which is caught by my code and reported to the user.
I am converting this site to Drupal 9. Other than details like how the API is wrapped, it's identical to the D7 version: its code is exactly the same as the example above.
But for some reason, if the third-party code finds a problem with the data, Drupal catches the exception before my code can see it, logs it to watchdog, and returns a 500-coded White Screen Of Death (which is of no use to the calling JS, which is expecting a sensible result).
Question: how do I turn this behaviour off, so the exception reaches my try/catch? It's not the first time I've run up against Drupal 9 getting in the way of handling errors, but it is the first time I've been completely unable to code around the problem.
Related
I'm currently develloping an extension in Typo3 10.4 and I can't working out a problem
I'm using some external libs for mailing or payments which sometimes throw exceptions.
My problem is that when this is happening i got an OOPS error even if I try to catch the exception
for exemple :
//CODE BEFORE
try{
//SOME CODE WHO SENDS EMAIL AND SOMETIMES THROW EXCEPTION
//BECAUSE THE CONNECTION FAILED
}catch(Exception $e){
//DO SOMETHING
}
//CODE AFTER
And it's a pretty annoying problem because some DB actions are not completed then
I'm sure there is a way to deal with the exception without stopping all the script but i don't know how...
Can someone help plz?
Thanks guys
Your approach is correct and TYPO3 shouldn't interfere. Thus, there seems to be another issue, so a few things to consider here:
Please keep in mind that your TYPO3 extension code is namespaced, if you really catch(Exception $e) it means \Your\Namespace\Exception - you probably want catch(\Exception $e).
That said, additionally configure a way to show the exception stack trace instead of "Oops" as output (the more simple approach, see e.g. How do I enable Error Reporting in TYPO3?) or connect a remote debugger like xdebug (more advanced) in order to see more than the Oops and get the real cause of the error and how it propagates.
If you aren't able to change the actual TYPO3 system you work on for reasons, an alternative could be to use an easy to set up local dev system like DDEV. This offers a simplified way to create a local TYPO3 instance, see e.g. the TYPO3 blog article
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'm creating a Forge application which needs to get version information from a BIM 360 hub. Sometimes it works, but sometimes (usually after the code has already been run once this session) I get the following error:
Exception thrown: 'Autodesk.Forge.Client.ApiException' in mscorlib.dll
Additional information: Error calling GetItem: {
"fault":{
"faultstring":"Unexpected EOF at target",
"detail": {
"errorcode":"messaging.adaptors.http.flow.UnexpectedEOFAtTarget"
}
}
}
The above error will be thrown from a call to an api, such as one of these:
dynamic item = await itemApi.GetItemAsync(projectId, itemId);
dynamic folder = await folderApi.GetFolderAsync(projectId, folderId);
var folders = await projectApi.GetProjectTopFoldersAsync(hubId, projectId);
Where the apis are initialized as follows:
ItemsApi itemApi = new ItemsApi();
itemApi.Configuration.AccessToken = Credentials.TokenInternal;
The Ids (such as 'projectId', 'itemId', etc.) don't seem to be any different when this error is thrown and when it isn't, so I'm not sure what is causing the error.
I based my application on the .Net version of this tutorial: http://learnforge.autodesk.io/#/datamanagement/hubs/net
But I adapted it so I can retrieve multiple nodes asynchronously (for example, all of the nodes a user has access to) without changing the jstree. I did this to allow extracting information in the background without disrupting the user's workflow. The main change I made was to add another Route on the server side that calls "GetTreeNodeAsync" (from the tutorial) asynchronously on the root of the tree and then calls it on each of the returned children, then each of their children, and so on. The function waits until all of the nodes are processed using Task.WhenAll, then returns data from each of the nodes to the client;
This means that there could be many api calls running asynchronously, and there might be duplicate api calls if a node was already opened in the jstree and then it's information is requested for the background extraction, or if the background extraction happens more than once. This seems to be when the error is most likely to happen.
I was wondering if anyone else has encountered this error, and if you know what I can do to avoid it, or how to recover when it is caught. Currently, after this error occurs, it seems that every other api call will throw this error as well, and the only way I've found to fix it is to rerun the code (I use Visual Studio so I just rerun the server and client, and my browser launches automatically)
Those are sporadic errors from our apigee router due to latency issues in the authorization process that we are currently looking into internally.
When they occur please cease all your upcoming requests, wait for a few minutes and retry again. Take a look at stuff like this or this to help you out.
And our existing reports calling out similar errors seem to point to concurrency as one of the factors leading up to the issue so you might also want to limit your concurrent requests and see if that mitigate the issue.
Ok, here is a strange one.
For testing this issue I have a endpoint like this:
[HttpPut]
public string Put(object value)
{
return value != null ? "ok" : "fail";
}
When throwing data directly at it the value object allways becomes the JSON i throw at it (as expected). However the app I'm developing requires me to go through a gateway that adds security to the call by verifying some headers and so.
When going through the gateway that forwards to my endpoint everything also seems ok until the body of the call hits a certain size(apperantly 471 chars is ok 472 is not) then the value object is null (and the therefore the method returns 'fail').
All this led me to believe that the GW truncates the body at a certain size and therefore makes it invalid JSON and the value object becomes null. BUT after talking to the provider of the gateway they told me that they tested it and this could not be the issue.
Here comes the really strange part
In my further pursuit of the problem I added a BeginRequest listener like this:
context.BeginRequest += Application_BeginRequest;
I added only one line to the interceptor for debugging purposes (to see if the body got truncated):
HttpContext.Current.Request.SaveAs("c:\\test.txt", true);
After adding this line everything works like a charm, all call gets thru (regardless of size) and value is never null. I tried removing the line again and we are back to the original issue where it fails at a certain size.
What on earth is going on
I really need some advice here on how to proceed debugging this issue.
Turned out to be an issue in the 3rd party GW anyways. The are now trying to fix the problem.
The iOS app I am making can have multiple webViews loading the same url at the same time. Resulting in this error:
Error Domain=NSURLErrorDomain Code=-999 "The operation couldn’t be completed.
(NSURLErrorDomain error -999.)" UserInfo=0x176b7bc0 {NSErrorFailingURLKey=https://example.com,
NSErrorFailingURLStringKey=https://example.com}
I read this happens when a new request is started before the old request has been completed. How do I prevent this from happening? Thanks
I spent weeks worrying about this error. I was getting it randomly while accessing web pages. In my case I put it down to pages being requested too quickly back to back as the web access was driven by a state machine in code and not by a user.
After much searching, in the end I found a few discussions which could not explain why the error was occuring, but it was felt that it was feature of UIWebView rather than something you should worry about. The guidance was to ignore it. I will see if I can find the article and update this answer later if I can find it.
I updated my code as follows, and so far have seen no ill effects at all since adding it. This would suggest it is almost a notification and anything which causes it seems to get corrected inside UIWebView. Hopefully this is the same in your case.
- (void)webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error
{
VSSLog(#"Entry: error = %#",error);
// Added this based on net advice. Its a bogus error.
if ([error code] == NSURLErrorCancelled) {
return;
}
... Normal error handling code for proper errors.
}
I am not one for out of sight out of mind, but this I believe is one of those cases where it is ok.
Finally if you are using iOS8 only, you could try moving to use the new WKWebView rather than UIWebView.
Use the delegate methods. Determine which view fired the method then fire the next if you're looking to run them sequentially.
- (void) webViewDidFinishLoad:(UIWebView *)webview{
if ( webview == self.wView1 )
{
// stuff
} else if ( webview == self.wView2 ) {
// stuff 2
}
}
UITableViewDelegate Protocol Reference