What is the difference between throw new Error and using Meteor.Error()? Is it simply that throw new Error will not be shown to the client, only on the server (the client will get a 500 Internal server error); and Meteor.Error will be sent to the client.
Are there any more differences? E.g. Does one break out of Fibers, stops downstream code?
The main thing with Meteor.Error is like you mentioned
A full stack trace (may not be given by Error always)
Possibility to send the error down to the client, in a limited non revealing form.
Hide the error from the server in certain cases (if its thrown in a method or publish method, and from hooks such as Accounts.onLoginAttempt)
The objects inside are EJSON serialised so a variety of data can be sent down to the client
When a Meteor.Error is thrown, because of the EJSON serialisation you get a bit more information on the server side.
Meteor displays the errors better.
Often you can get [Object object] as the reason to be displayed from ordinary errors when they come from ordinary Errors, from Meteor.wrapAsync
Theres not much else that's different, Meteor.Error is a a subclass of Error with the above changes.
So they'll both stop downstream code. When it comes to Fibers, if the ordinary one is thrown out of a Fiber in any way its likely to stop your app (on the server side & not in a method, startup, Meteor.setInterval, publish, etc)
Its definition is also quite small: https://github.com/meteor/meteor/blob/devel/packages/meteor/errors.js
Related
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
I have a Back-to-Back call from caller to our ucma server to client/operator. When doing a transfer on the leg from caller to ucma, there are a few different results which can happen; the transfer target answers, doesn't answer or ignores the call (ignore/busy button).
I want to differentiate between the later two; busy and no answer. In the ucma application I only get a FailureRequestException with text "The transfer operation failed. For more information, refer to the message data in the exception."
I cannot figure out anywhere in the exception or otherwise how to know the difference between busy and no answer. Both generates the same exception with no obvious parameter saying whichever it is.
Is there any way I can know the reason the transfer failed in this scenario?
I'm not sure if this will help, but if you can get the final non-provisional status code for the invite, a "ignore" end will be a 603. A no answer will be a "480" - altho a 480 (Temporarily Unavailable) can be returned for lots of other reasons.
Also the situation can be confused if the user has more than one endpoint (e.g. Desktop Lync Client and Mobile Lync Client). So you end up with forked requests / responses with only one overall response back to you. Then you may not always be able to tell exactly why the call was terminated.
I actually find it funny you are saying you get a FailureRequestException.
I would be expecting a FailureResponseException. With a FailureResponseException exception you can pull out the status code.
From the UCMA 4.0 exception model msdn page:
FailureResponseException
Thrown when a 4xx, 5xx, or 6xx response was received for a request. This exception contains the ResponseData property, which
contains the complete response including response code, reason text,
headers, and message body. In some rare cases, this may also be thrown
when an error other than a 4xx, 5xx, or 6xx response occurred. In such
cases the ResponseData property is null.
I'm having a discussion with a colleague about when to throw faults and when not to throw faults in a WCF service.
One opinion is, that we only throw faults when the service operation could not do its work due to some error; and something may be in an invalid state because of it. So, some examples:
ValidateMember(string name, string password, string country)
-> would throw a fault if the mandatory parameters are not passed, because the validation itself could not be executed;
-> would throw fault if some internal error occured, like database was down
-> would return a status contract in all other cases, that specifies the result of the validation (MemberValidated, WrongPassword, MemberNotKnown,...)
GetMember(int memberId)
-> would only throw fault if something is down, in all other cases it would return the member or null if not found
The other opinion is that we should also throw faults when GetMember does not find the member, or in the case of ValidateMember the password is wrong.
What do you think?
My take on this...
There are three causes of failure:
The service code threw an exception, e.g. database error, logic error in your code. This is your fault.
The client code failed to use your service properly according to your documentation, e.g. it didn't set a required flag value, it failed to pass in an ID. This is the client software developer's fault.
The end user typed in something silly on screen, e.g. missing date of birth, negative salary. This is the end user's fault.
It's up to you how you choose to map actual fault contracts to each cause of failure. For example, we do this:
For causes 1 and 2, all the client code needs to know is that the service failed. We define a very simple "fatal error" fault contract that contains only a unique error ID. The full details of the error are logged on the server.
For cause 3, the end user needs to know exactly what he/she did wrong. We define a "validation errors" fault contract containing a collection of friendly error messages for the client code to display on screen.
We borrow the Microsoft EntLib class for cause 3, and use exception shielding to handle causes 1 and 2 declaratively. It makes for very simple code.
To Clarify:
We handle the three causes like this inside the service:
An unexpected exception is thrown in the service code. We catch it at the top level (actually exception shielding catches it, but the principle is the same). Log full details, then throw a FaultException<ServiceFault> to the client containing only the error ID.
We validate the input data and deliberately throw an exception. It's normally an ArgumentException, but any appropriate type would do. Once it is thrown, it is dealt with in exactly the same way as (1) because we want to make it appear the same to the client.
We validate the input data and deliberately throw an exception. This time, it's a FaultException<ValidationFault>. We configure exception shielding to pass this one through un-wrapped, so it appears on the client as FaultException<ValidationFault> not FaultException<ServiceFault>.
End result:
No catch blocks at all inside the service (nice clean code).
Client only has to catch FaultException<ValidationFault> if it wants to display messages to the user. All other exception types including FaultException<ServiceFault> are dealt with by the client's global error handler as fatal errors, since a fatal error in the service generally means a fatal error in the client as well.
It it is a common, routine failure, then throwing a fault is a mistake. The software should be written to handle routine items, like entering the wrong password. Fault processing is for exceptional failure which are not considered part of the program's normal design.
For example, if your program was written with the idea that it always has access to a database, and the database is not accessible, that's an issue where the "fix" is well outside of the limits of your software. A fault should be thrown.
Fault processing uses different logical flows through the structure of the programming language, and by using it only when you've "left" the normal processing of the programming problem, you will make your solution leverage the feature of the programming language in a way that seems more natural.
I believe it is good practice to separate error handling and fault handling. Any error case should be dealt by your program - fault handling is reserved for exceptional conditions. As a guide to the separation of the two I found it useful when considering such cases to remember that there are only three types of error (when handling data and messages) and only one type of fault.
The error types are related to different types of validation:
Message validation - you can determine from the message contents that the data is valid or invalid.
Example: content that is intended to be a date of birth - you can tell from the data whether it is valid or not.
Context validation - you can only determine that content is invalid by reference to the message
combined with the system state.
Example: a valid date of joining a company is earlier than that persons date of birth.
Lies to the system - you can only determine that a message was in error when a later message
throws up an anomaly.
Example: Valid date of birth stored and inspection of the person's birth certificate shows this to be incorrect. Correction of lies to the system generally require action outside of the system, for instance invoking legal or disciplinary remedies.
Your system MUST deal with all classes of error - though in case three this may be limited to issuing an alert.
Faults (exceptions) by contrast only have one cause - data corruption (which includes data truncation). Example: validation parameters are not passed.
Here the appropriate mechanism is fault or exception handling - basically handing off the problem to some other part of the system that is capable of dealing with it (which is why there should be an ultimate destination for unhandled faults).
In the old days we used to have a rule that exceptions were only for exceptional and unexpected things. One of the reasons you did not want to use them too much was that they "cost" alot of computing power.
But if you use exceptions you can reduce the amount of code, no need for alot of if else statements, just let the exception bubble up.
It depends on your project. The most important thing is that there is a project standard and everyone does it the same way.
My opinion is that exceptions/fault should be thrown whenever what the method is supposed to do can't be achieved. So validation logic should never raise exception except if the validation can't be made (i.e. for technical reasons) but never just because the data are not valid (in that case it will return validation codes/messages or anything helping the caller to correct the data).
Now the GetMember case is an interesting one because it's all about semantic. The name of the method suggest that a member can be retrieved by passing an id (compare to a TryGetMember method for exemple). Of course the method should not throw the same exception if the id is nowhere to be found or if the database does not respond but a wrong id passed to this method is probably the sign that something is going wrong somewhere before that call. Except if the user can directly enter a member-id from within the interface in which case a validation should occurred before calling the method.
I hear a lot about the performance issue. I just made a simple test using C# and trow/catch 1000 exceptions. The time it took is 23ms for 1K Exeptions. That's 23ยต per exception. I think performance is no longer the first argument here except if you plan to raise more than 2000 exception per second in which case you will have a 5% performance down, which I can start considering.
My humble opinion...
I'm running two glassfish v2 domains containing stateless session EJBs. In a few cases, an EJB in one domain has to call one in the other.
My problem is that when the called EJB aborts with an exception, the caller does not receive the message of the exception and instead reports an internal error that is not helpful at all in diagnosing the problem. What happens seems to be this:
At the transport layer, a org.omg.CORBA.portable.ApplicationException is created,which already loses all detail information about the exception except its class.
Inside com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), the status of the transaction ass rolled back causes a org.omg.CosTransactions.Unavailable to be thrown, which gets wrapped and passed around a few times and eventually results into this error being displayed to the user:
org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
Is there anything I can do here to preserve information about the actual cause of the problem?
The cause of the problem should be available in the server log of the domains hosting the EJB that had a problem.
It sounds like getting more info back from the other end may be difficult... I do not know which issue tracker would be the right one for the info lost when the ApplicationException is created/thrown.
A total hack would be to create a set of custom exception classes in the project that has the ejb that has failed. You would make them very fine grained to cover the likely causes of the problem and provide enough detail in their name to identify the actual location of the problem, too. Yucky... but that may be the only choice until an issue gets filed and the fix is distributed.
Is there anything I can do here to
preserve information about the actual
cause of the problem?
Unfortunately, no. The ORB does not use normal object serialization for system exceptions (i.e., org.omg.CORBA.*), which means that causes are lost. As #vkraemer said, you'll need to rely on server logs.
I finally got to the bottom of this: actually, Glassfish transmits exceptions through IIOP quite correctly and everything works as it should... unless you do something idiotic like this:
try{
ejb.getFoo();
}catch (Exception e){
// try again
ejb.getFoo();
}
Yeah, it was our own damn code that swallowed the exception and tried to call a transaction-requiring EJB method within a distributed transaction that's been rolled back due to the exception.
Generally, in software design, which of the options below is preferred when there is a problem or error with a resource such as a database or file?
Show an error message
Do not show an error message and act as though the resource was empty (eg. do not populate a GUI component)]
For example, should the user see an empty DataGrid following which they complain, or should there be an error message? Which is better?
I don't see this as an either/or. Also, we need to consider all "users" of the system.
First consider the UI. Let's consider a contrived general case: you are populating a UI by calling a service which in turn uses a couple of of databases (for example a "current data" and an "historic data") database.
There are at least these possibilities:
It all works, data is retrieved
It all works but as it happens there's no data for this particular query
Can't reach the service
Service is invoked, but one database is down
Service is invoked, but both databases are down
Then also consider your application's semantics. Can your applciation procede in a "degraded" mode if all the data cannot be retrieved? For example, we can't query the history but that doesn't stop us creating a new item.,
Now also consider the roles here. There's the person using the UI, there's also support and maintenance people who need to know about and fix problems.
My general rules:
First Failure Data capture: Whichever component first detects an error should log it in some detail. So, service up, database down the service should log the problem. Service down, the UI should log the problem. This log should be a technical record targeting the support roles.
UIs should be tolerant: if at all possible run in a degraded mode. So if the service is down but (for example) local working is possible put up an empty screen and continue. BUT ...
Always indicate a problem: The "no data for this query" and "databases unavailable" cases may both result in an empty screen. The user needs to know the status of the display, is it showing complete information, partial information (eg. because one DB is down) or is no information available (eg. service or both dbs down). So have a "Status" field somewhere on the screen. Giving messages such as
Historica Data not currently available
or
There are problems retrieveing
information, if these persist please
contact support ...
There are some pitfalls to each of the options
Showing error message
This is specially helpful when your application is in testing stage or public testing. Also when clients meets an error, he or she can copy down the details and forward to you.
However sometimes this error message gets very ugly (call stacks and so on - remember ASP.NET?) and it becomes so large that it becomes difficult for clients to copy down the details.
Do not show error message and act as though nothing happened =)
This is useful when you don't want error messages to cog up your software UI design. But be reminded that it becomes difficult and further error prone when clients can't differentiate between an actual error, or really nothing on the GUI. The error stays there and nothing gets fixed.
My stand
Get the best of both worlds. In fact most modern applications how have a very good error handling process. I'll take the example of Mozilla Firefox 3.
A deadly error occurred and Firefox crashes
Error is captured and stored into a file as a form of error report
Error Reporting Application pops up apologizing to the user
Ask the user if the user want to send the error report to the software dev team
Then ask the user if want to restart the application
Or if the error is a warning or of lesser severity:
Show a simple error code and tell the user that there's the error with that action. Something like: "Error 123 at RequestSalary() Line 2"
The practice I usualy use is:
If the error didn't happen due to user error, then you should try to handle the error quietly.
If the error occurred because of some external problem (such as no internet connection) then you should alert the user.
IMO you should show a message (albeit a user friendly one and not something like "java.io.IOException: Connection timed out".) You could have a message box telling the user that an error occured while getting the data and provide helpful tips like: Trying after some time, check network cable, etc.
Also allow user to report that error to you (error reporting build into the app) that will send you the actual error and stack trace.