I want to catch php errors so i used set_error_handler('handler_function') when i echo the error message , 'Zend_Controller_Response_Exception' with message 'Cannot send headers; headers already sent' is thrown when i used the following lines
$fc=Zend_Controller_Front::getInstance();
$fc->getResponse()->setBody($error);
an error happened 'call to setBody method of a non-object'
i tried to throw an exception from the error handler but this depend on the error occurring before bootstrapping is displayed directly after bootstrapping displayed in errorController
i used $fc->throwExceptions(false) to ensure it will send exceptions to error controller
when i do nothing in the error handler the execution is continued
what i need is to have one place to handle all errors
if there is a way to redirect to the error controller with error in params this will be good
IMO best way to handle these errors is to register error handler that will convert any error/fatal error to exception. I guess that response is not created yet. You have to use $fc's setResponse() method to create new response. I would guess that converting to exception should work in any case. Same as exceptions from Zend classes work.
Related
Fairly new to Mirth, so looking for advice in regards to debugging/getting more information from errors reported in the Server Log in Mirth Connect. I know what channel this is originating from, but that's about it. This error is received 10 times for each message coming through. It should be noted that the channel is working properly except for this error cluttering up the logs.
The Error:
ERROR (transformer:?): TypeError: undefined is not an xml object.
What I've Tried:
Ruled out Channel Map variables (mappers), they don't have null default values, they match up with vars in the incoming xml message, even changed to Javascript transformers to modify the catch to try to narrow down the issue, but no luck.
Modified external javascript source files to include more error handling (wrapped each file in a try/catch that would log with identifying info) but this didn't change the result at all.
Added a new Alert to send info if errors are received, but this alert never fired.
Anything else to try? Thanks for any/all help!
This is a Rhino message that happens when you use an e4x operator on a variable that isn't an xml object. The following two samples will both throw the same error you are seeing when obj is undefined. Otherwise, 'undefined' in your error will be replaced with obj.toString();
// Putting a dot between the variable and () indicates an xml filter
// instead of a function call
obj.('test');
// Two consecutive dots returns all xml descendant elements of obj
// named test instead of retrieving a property named test from obj.
obj..test;
I have a route /products. In App.ProductsRoute, I am using a setupController hook to assign list of products fetched from server to local App.Product objects.
I am setting the model in setupController hook as :
self_controller.set('model', self_controller.store.find('product'));
This works well when HTTP status is 200. But when server returns some HTTP error (like 500-Internal Server Error, 401-Unauthorized Errors, etc) I am getting error as JSON.parse. I am not sure how to handle errors for this.store.find() calls.
Note: It returns Ember's promiseArray which I need to check once resolved (before actually assigning it to model). Any help on this topic would be much appreciated. Thanks.
What about using the promise's catch callback to handle the errors? Untested, but something like this should work:
self_controller.store.find('product').then(function(products) {
self_controller.set('model', products);
}).catch(function(reason) {
// Do something to handle the error response...
});
My use case is that I would like to do error handling in sinatra. For this I am setting up the error handler as follows
error 0..600 do
##logger.error("error reason #{env['sinatra.error']}")
end
The sinatra.error variable gets set fine if the error was caused by explicitly raising an exception
get '/' do
raise "Fail the request"
end
But if halt is used to terminate the request then sinatra.error does not get set. Looking into sinatra code this appears to be as expected because throwing :halt causes the control flow to go all the way up to invoke and thus bypassing the setting of sinatra.error variable.
My question is how to use the error handler along with the halt so that I can get the cause of the error in the error handler.
I think the behavior you're seeing stems from the intended purpose of halt. When you call it, you aren't necessarily signaling in error; you just want execution to stop immediately, which can be particularly useful in a filter. If you check Sinatra's README, it says that you use halt to "immediately stop a request within a filter or route use". Granted, you will usually do it because of an error.
It is also interesting to notice that the error handler you defined gets called not only when errors occur, but also when regular requests are served, including ones with status 200. And in those cases, env[sinatra.error] won't be set either.
What you can do in your error handler is to check for an exception and, if it's not available, check the response code. For example (note that this is a classical application):
error 0..600 do
boom = #env['sinatra.error']
status = response.status
case
when boom != nil
puts 'exception: ' + boom
when status != 200
puts 'error: ' + status
end
end
One consequence is that, in this handler, normal requests are indistinguishable from those interrupted by halt, because both generate a 200 status code. However, if you are using halt to report errors, then you should be using an error code like 500 anyway.
I have created a REST service using WCF for communicating with BLL/DAL from UI. Now, I would like to implement Exception Handling through some globalize way in REST. I am using HTTPClient to communicate with REST from client. The following are the ways, I have implemented exception handling:
Approach 1:
OutgoingWebResponseContext response = WebOperationContext.Current.OutgoingResponse;
response.StatusCode = System.Net.HttpStatusCode.Unauthorized;
response.StatusDescription = ex.Message;
success = false;
Approach 2:
throw new WebProtocolException(HttpStatusCode.NotFound, ex.Message, null);
but somehow I am not able to catch them in the client side. Kindly suggest some pointers in order to handle exceptions raised by service globally.
I am throwing WebProtocolException (Approach 2) along with error code and error message from the service to UI in order to notify users about the exception. I am able to receive the error code in UI side but not getting error message or detail.
Then I created another service (having .svc extension) and added following line to the service's markup: "Factory='Microsoft.ServiceModel.Web.WebServiceHost2Factory'". Now, I am able to receive the error message along with error code on client side (UI).
Can anybody let me know how to use the WebServiceHost2Factory method in my existing service which is a class file instead of .svc file?
Any suggestions will be highly appreciated. Thanks
HttpClient does not throw exceptions when a response comes back that is not "successful". If you really want exceptions to be thrown on the client side, then call
response.EnsureResponseIsSuccessful();
Otherwise, just check the status code on the client and decide what to do based on that value.
You cannot throw exceptions on the server and expect the exceptions to be propagated to the client. HTTP does not have any notion of exception.
We're using a $server = SOAP::Transport::HTTP::Apache->new; $server->dispatch_with(...) over here as a backend to a JS-based application. Should the underlying module die, it sends back a nice error message that gets displayed by the JS code.
The problem is, I would like more detailed messages (e.g. Carp::longmess), and a hard copy of those on STDERR.
How can I inject a custom exception handler into SOAP::Transport::HTTP::Apache with minimal code modifications?
(This is a large and old project we can't afford to rewrite, though honestly it deserves a rewrite).
UPDATE: here's a sample error message:
<soap:Body><soap:Fault>
<faultcode>soap:Server</faultcode><faultstring>Column
'allocation' cannot be null at
/usr/local/lib/perl5/site_perl/5.8.8/Tangram/Storage.pm
line 686. </faultstring></soap:Fault></soap:Body>
I get a Tangram error but this is unlikely a bug in Tangram and anyway I need a full stack-trace. OTOH, the die message got into a SOAP message which is not a normal die action so there's a handler somewhere -- which I want to customize a bit.
The error handler is located under SOAP::Transport::HTTP::Server::_output_soap_fault. Try a grep on <faultcode> in the perl INC paths.