I'm just using NewRelic error trapping for my coldbox application. From OnException method, I'm just sending the error struct to log the error.
My code in onexception method
public function onException(event,rc,prc){
NewRelic.logError( prc.exception.getExceptionStruct());
}
The logerror() method resides in NewRelic.cfc and contains the following code
public boolean function logError(
required struct exception
) {
var cause = arguments.exception;
var params = {
error_id = createUUID(),
type: arguments.exception.type,
message: arguments.exception.message
};
writeDump(this.newRelic);
this.newRelic.noticeError(cause, params);abort;
return true;
}
So while error, I'm gettig the following error.
The noticeError method was not found.
You can see that, the noticeError() method is there in the object, but it is overloaded with arguments.
I'm using the same code for NewRelic error trapping in another coldfusion project without any frameworks.
Calling error.cfm through Cferror tag, and the code in error.cfm as follows
<cfset Application.newRelic.logError( variables.error )>
And in NewRelic.cfc, the logerror() method contains the same code as in the coldbox application. But it is logging errors in NewRelic without any issues.
This is the method I need to notice errors and log it in NewRelic.
noticeError(java.lang.Throwable, java.util.Map)
So I just thought to get the classname of the first argument Cause through the following code from both applications within logError() in NewRelic.cfc, to get the difference.
writeDump(cause.getClass().getName());
I'm getting
coldfusion.runtime.ExceptionScope for Coldbox application
and
coldfusion.runtime.UndefinedVariableException for normal coldfusion application
The cause argument is not throwable from coldbox application. So how to get the original error struct from coldbox application? and make it throwable to fix the noticeError method was not found issue.
The change in the underlying class happens when ColdBox duplicates the error object with CFML's duplicate() method. I doubt that ColdFusion behavior is documented anywhere, but I don't see an easy way to get around it right now other than creating your own instance of a java.langException and populating it with the details of the original error.
If you want to modify the ColdBox core code, this happens here:
https://github.com/ColdBox/coldbox-platform/blob/master/system/web/context/ExceptionBean.cfc#L43
I have entered this ticket for the ColdBox framework for us to review if we can stop duplicating the error object in future versions of the framework.
https://ortussolutions.atlassian.net/browse/COLDBOX-476
Update: Adam Cameron pointed out this ticket in the Adobe bug tracker that details this behavior in the engine. It was closed as "neverFix".
https://bugbase.adobe.com/index.cfm?event=bug&id=3976478
Related
I have a java project written using spring-cloud-function and deployed in aws-lambda.
I am trying to return a custom exception with some fields in the exception message body, something like"
{
reason: <exception reason>
code: <error code>
<some other fields>
}
#ExceptionHandler, that is generally used in spring boot doesn't seem to work here.
I can return the exception in the required format by creating a class for building the exception message in required format but in that case the error code will always be 200 since it will not be an exception object per se. Instead it will be my custom error object.
Is there a way I can set this up so that the above required format of exception object is returned and correct error code can be returned too?
Thanks in advance
First, the exception has nothing to do with Spring Boot. It's part of spring-web, so yes it would not work here since s-c-function is a general purpose framework, where the same function could be deployed and triggered via web, streaming, aws-lambda etc. .
Now, yes we had a problem returning JSON error (as you show) or object that represents the same, but that was fixed. So please update s-c-function to 3.2.3.
I am using RESTier 0.6.0 library and would like to perform some checks on a resource before deleting it. In the event that the checks fail, I am throwing an Exception to stop the delete operation. However, the error message that I am using to instantiate the Exception is not getting pushed out at the highest level. I can only view the message as an inner exception when serving my Web API from Visual Studio. Is there a way to get this error message to push out at the highest level?
protected void OnDeletingGw_Pack(Gw_Pack pack)
{
var trades = ModelContext.Gw_PackJunction.Where(e => e.PackID == pack.PackID).ToList();
if (pack.Groupage == true || trades.Count > 1)
{
// Don't delete a pack if it is a groupage container or if it's associated with more than one Trade.
throw new Exception("The container you are trying to delete is either marked as groupage or is functioning as a groupage container in another file.");
}
}
Currently any Exception thrown within the OnDelete submit logic methods in the EntityFrameworkApi results in an error which looks like this:
{
"error":{
"code":"","message":"An error has occurred."
}
}
... which is not particularly useful to the client.
UPDATE: I noted in the RESTier documentation MkDocs version that an example was given where an ODataException (rather than Exception) was thrown. I changed this in my code, but the error object returned by the published Restier service still only has the basic "An error has occurred" information.
Assistance is greatly appreciated!
When throwing an Exception within the RESTier EntityFrameworkApi (inside and OnUpdate<EntitySet> method for example), the exception is deserialized as part of the inner exception (internalexception). So in order to view any exceptions thrown within the RESTier API, one needs to...
set the IncludeErrorDetailPolicy property on the HttpConfiguration
class like this:
config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always
Structure of error received by client
See this post: OData controller returns different error for local and different for remote machine
I created a custom component for a proprietary service. If this service is down i get noticed via a call of a callback function. I am throwing a custom exception at this point.
Sending exchanges to the producer/ consumer will yield no errors or exceptions (all seems to fine).
So i need to implement an emergency stop if my custom exception is thrown. I read a bit about exception handling in camel. I think i need a context-scoped onException(MyException.class).??? but what then?
Is this working on exceptions that are called without relation to an exchange? If this is working how to handle it. I want to stop certain routes in this case.
here you can find to stop routes from a route: http://camel.apache.org/how-can-i-stop-a-route-from-a-route.html.
If you do the call of the proprietary service in a route you do have an exchange btw.
kind regards,
soilworker
I created a little workaround: I set a boolean i the callback method is called. On each call of process i check this boolean and if true i throw an exception.
With this the exception is within normal camel exception handling and onException could be used.
I'm working on a project and I become always an Exception "TypeInitializationException".
I tried to give a string to a global string variable but it failed.
That's the code for the viewmodel and it failed on the second line
| {State = _}, ConsumablesClicked vm ->
Testtyp <- vm.TrackPosition.ToString()
That's on the other program
let mutable Testtyp = ""
I become this InnerException "Cannot read keys when either application does not have a console or when console input has been redirected from a file. Try Console.Read.".
"The type initializer for '.$BarcodeGenerieren' threw an exception.", that's the exception explication.
Has someone a Idea how solve this?
That exception indicates that some code is trying to call Console.ReadKey when the standard input for that process has been redirected (see e.g. Allowing redirection of StandardInput of a C# application when doing "Console.ReadKey"). The solution is not to call Console.ReadKey, but it's not clear from your description where this is actually happening (perhaps in the static constructor for one of your types?).
I found the solution after a lot of try and it was only, that I had a Console.Readkey in my code, that I forgot to delete.
I had before a console apllication and I transformed it to be a class.
We are developing a proxy in WCF that will serve as a means of communication for some handhelds running our custom client application. I am curious what error handling strategies people use as I would rather not wrap EVERY proxy call in try/catch.
When I develop ASP .NET I dont catch the majority of exceptions, I leverage Application_Error in Global asax which can then log the exception, send an email, and redirect the user to a custom error landing page. What I am looking for in WCF is similar to this, except that it would allow me to pass a general faultreason to the client from a central location.
Basically I am curious how people centralize their exception handling in WCF apps.
Thanks
You might find the IErrorHandler interface useful here. We've been using this to do pretty much what you mention - centralised exception logging and providing generalised fault reasons without having to litter the code with numerous try/catches to try and deal with the problem locally.
So here is what I did. We have a few custom exceptions in our application such as BusinessRuleException and ProcessException, WCF supports both FaultException and FaultException<T>.
General practice seems to be that you always throw FaultException to the client in the case of a general error or an error that you dont want to display exactly what happened. In other cases you can pass FaultException<T> where T is a class with information about the particular exception.
I created this concept of Violations in the application, which basically meant that any custom exception had a property containing the corresponding Violation instance. This instance was then passed down to the client enabling the client to recognize when a recoverable error had occured.
This solved part of the problem, but I still wanted a general catch all that would allow me to centeralize logging. I found this by using the IErrorHandle interface and adding my own custom error handler to WCF. Here is the code:
public class ServiceHostGeneralErrorHandler : IErrorHandler
{
public void ProvideFault(Exception ex, MessageVersion version, ref Message fault)
{
if (ex is FaultException)
return;
// a general message to the client
var faultException = new FaultException("A General Error Occured");
MessageFault messageFault = faultException.CreateMessageFault();
fault = Message.CreateMessage(version, messageFault, null);
}
public bool HandleError(Exception ex)
{
// log the exception
// mark as handled
return true;
}
}
Using this method, I can convert the exception from whatever it is to something that can be easily displayed on the client while at the same time logging the real exception for the IT staff to see. So far this approach is working quite well and follows the same structure as other modules in the application.
We use the Exception Handling Application block and shield most faults from clients to avoid disclosing sensitive information, this article might be a good starting point for you, as with "best practices" - you should use what fits your domain.