I'm working on an API project and have to decide over the error handling and logging strategy/concept. So as first step I want to check, whether Apigility provides its own logging functionality.
If I see it correctly, Apigility only provides a minimal error handling for REST specific errors (Apigility documentation -> Error Reporting). That's it. So, only a limited error handling and no logging. Right? But maybe it's wrong and I have just not found the functionality I need. So, is an error handling mechanism provided? Is a logging mechanism provided in Apigility?
It handles error rendering if you use ApiProblem objects to encapsulate your errors.
It doesn't handle logging out of the box, you'll have to add your application's logging strategy yourself.
Related
How do I handle and return a human readable error in a Java Azure Function app?
All examples of this on a Google search, are just simple instructions on how to do a try-catch, which is not my question.
More specfically, how do we design the return status code and the response body of the request, in a way that provides the most flexibility to a wide array of situations?
Given that we are not integrating Spring-Boot in this case, and that we do not have access to anything Spring.
Given that my API generally returns an object that we will call Pojo1, on error, what is the best way to return a informative message.
NOTE: Of course, I do know there are situations where you want security through obscurity, in which case I would probably choose logging errors to app insights. This is not my question though.
Well, you can set custom headers while returning the request. This
can be done using a setHeader function.
You can also use azure service bus or event grid which will carry
specific messages regarding the errors.
Also, you can use azure monitoring which collect all the error and
notify you when everything happens.
Refer this article by Eugen Paraschiv for indepth explanation on how to use setheader.
Refer this documentation on azure service bus and this documentation on event grid.
Refer this documentation on azure monitoring logs.
Short Version
Please read at the very bottom for a short version of the question.
Situation
In a question I asked last week, I struggled in finding a solution, which makes our asp.net error visualization waterproof, since there are some edge cases where the asp.net exception handling fails and hence no proper exception visualizations can be created:
How to properly set up ASP.NET web.config to show application specific, safe and user friendly asp.net error messages in edge cases
Desired Solution
As an alternative to the way I described there, in my opinion the best way to make the exception visualization reliable, would be to use the httpErrors-element in system.webServer as a failsave so that any error which is not properly handled by asp.net, leads to a generic error page which is shown based on the settings of the httpErrors-element .
To accomplish this, there must be two things possible:
Error pages properly handled by the application must pass through iis without being replaced with a generic error message
Errors which could not be processed properly in asp.net, must be replaced through IIS.
It is my understanding, that this very behaviour is meant by the existingResponse="Auto" parameter in the httpErrors-element.
The ms documentation states:
Leaves the response untouched only if the SetStatus flag is set.
This is exactly what is necessary: Any successful error page creation in the application (through Application_Error or through an explicitly defined error handling page) can set
Response.TrySkipIisCustomErrors = true and IIS would let the error page pass through. However, every other error which was not successfully handled by the application in asp.net, would not set the flag and hence get the error page which is specified in the httpErrors-element.
The Problem
Sadly, it seems that in MVC5-applications (I don’t known whether the same behavior is true in other environments), the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) seems to be set automatically to [true], even if it is not set by the application.
Hence we are at the same place, as in my other post: If the error handling of the application blows, there is no way to show an application specific error with existingResponse="Auto", since its not possible to reset the fTrySkipCustomErrors flag.
As an alternative, one can set existingResponse="PassThrough". That's what we do currently, since we want to generate our error pages with a support-code and other helpfull information about the error to be shown to the user, or one can use existingResponse="Replace", but this is not an option, since it replaces any error page so that we don’t can show the user any error-specific information such as the support-code mentionen before.
Quesition in Short
The question is therefore, how to make sure that MVC5 (asp.net) does not set the fTrySkipCustomErrors flag automatically to [true], since there are situations, where no application code is executed and hence the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) cannot be set to false, what renders the existingResponse="Auto" parameter moot.
To check such a situation where the asp.net MVC5 exception handling blows but the fTrySkipCustomErrors flag is set to true, please request the following page from your MVC5 application:
http[s]://[yourWebsite]/com1
Please note: I'm not interested in disabling the above error. It's an example. I want the error visualization reliable and not to have to circumvent every error that possibly can blow asp.net's error handling mechanisms.
I am new to mulesoft and while studing it i strugle to understand why on module "onErrorPropagate" the error is being rethrown after executing the scope.
can you explain the benefits?
An on-error-propagate will rollback any transactions, execute, and use that result to rethrow the existing error––meaning its owner will be considered as “failing.”
The best use is in a layered system, to allow each layer to do its own small part of an error response.
If you are familiar with Java you can think of it as catching the exception and re-throwing it. For example, sometimes you want to do something with the error yourself, but still want to propagate it upwards for higher levels to deal with.
You could add logging in a specific flow for the error but then leave it to the parent flows to actually deal with the exception.
The "onErrorPropagate" propagates (rethrows) the error to the parent flow (or the global error handler if it's already reached the main flow).
This can be usefull in a few cases.
Say you have some flow specific error handling (e.g. if something goes wrong, set a default payload).
Then you propagate this error to the next level where you have your Global error handler that, say, stores some info in a QA database.
You don't want to have that database connector in every single error handler.
In this way you can achieve a 'java inherritance' like structure, for your errors.
Side note: if you want your error to only be handled and do nothing further, you can use "onErrorContinue"
My goal is to influence the error descriptions that appear in BizTalk Administration Console in the Error Information tab of suspended instance windows, after errors occur in my custom functoids. If possible, I would also like the ErrorReport.Description promoted property to display this error description on the failed message.
I've read everything I can find about custom functoid development, but I can't find much about error handling within them. In particular, whenever my functoids throw exceptions, I see the boilerplate "Exception has been thrown at the target of an invocation" message that occurs whenever exceptions occur through reflection, rather than the message on the exception itself.
I had hoped to find something within the BaseFunctoid class framework that would allow me to submit an error string, so as to traverse the reflection boundary. Is there some way to pass error information from within a custom functoid, such that the BizTalk Administration Console will display it?
If I emulate the approach taken by DatabaseLookupFunctoid and DatabaseErrorExtractFunctoid, is there some way I can fail the map with the extracted error, rather than mapping it to a field on the destination schema as is shown in its examples?
The simplest way to do this is using custom C#, writing something like this in your code:
System.Diagnostics.EventLog.WriteEntry("EVENT_LOG_SOURCE", "Error message...", System.Diagnostics.EventLogEntryType.Error);
As Johns-305 mentions, you need to make sure your event source is registered (e.g. System.Diagnostics.EventLog.CreateEventSource("EVENT_LOG_SOURCE", "Application") - but this should really be done as part of your installation steps with an EventLogInstaller or some kind of script to set up the environment). It's certainly true that error handling in BizTalk is just .NET error handling, but one thing to keep in mind is that maps are actually executing as XSLT, and the context in which their executing can have a major impact on how exceptions and errors will be handled, particularly unhandled exceptions.
Orchestrations
If you're executing a transform in an orchestration that has exception handling in it, the exception thrown will be handled and may even fall into additional logging you have in the orchestration - in other words, executing a throw from a C# functiod will work the way you'd think it would work elsewhere in C#. However, I try to avoid this since you never know if a map will at some point be used else where and because exception handling in XSLT doesn't always work the way you'd think (see below).
Send/Receive Ports
Unfortunately, if you're executing a map on a send or receive port and throw an exception within it, you will almost definitely get very unhelpful error message in the event log and a suspended instance in the group hub. There is no easy, straightforward way to simple "cancel" a transform - XSLT 1.0 doesn't have any specified way of doing that (see for example Throwing an exception from XSLT). That leaves you with outputting an error string to a particular node in the output (and/or to the EventLog), or writing lots of completely custom XSLT to try to validate input, or designing your schemas properly and using a validating component where necessary. For example, if you have a node that must match a particular regex, or should never be empty, or should never repeat more than X times, make sure you set those restrictions on the schema and then make sure you pass it through the XmlValidator or similar before attempting to map.
The simplest answer is, you just do.
Keep in mind, there is nothing special at all about error handling in BizTalk apps, it's just regular plain old .Net error handling.
So, what you do is catch the error in you code, write the details to the Windows Event Log (be sure to create a custom Event Source) and...that's it. That is all I do. I don't worry about what appear in BT Admin specifically.strong text
Short and simple:
How to catch pgPL/SQL exceptions with QtSQL?
I haven't found any example or info at the docs.
More details:
I'm developing the front end for a system with Qt 5.3. The database perform some validation at some of the inputs and raise custom exceptions when something is invalid. What I want is to be able to handle these exceptions at he front end code, showing appropriate messages to the user.
EDIT:
I have tried to use the QSqlError class. Although it gave me the exception, it gave me too much data which will need to be parsed to be useful. Is there a way to get the exception raised without parsing the messages?