I have a set of RIA domain services that use an overriden OnError operation to throw DomainExceptions. This works perfectly and allows the silverlight client to identify the base exception types via the embedded error code. However my RIA service operations are attributed to include a number of implementaions of IOperationInvoker to inject pre-invoke and post-invoke behaviour.
If an exception is thrown by any of the code in these IOperationInvoker operations the silverlight client gets a DomainOperationException containing a FaultException. Even though the thrown exception is a FaultException the received fault appears be be devoid of any the original detail only containing the textual message.
I have tried catching the exception in the IOperationInvoker and converting it to a DomainException but this does not change what is visible in Silverlight.
Is there any way I can throw an Exception from the IOperationInvoker so that it is surfaced in the Silverlight client as a DomainException i.e. including the error code as if it had come from the DomainService operation that is wrapped by the IOperationInvoker?
Related
For the last two years we've been developing a web based application with ASP.NET MVC 3, NHibernate (v. 3.3.1.4000) and PostgreSql for back-end database, therefore using the Npgsql driver (v. 2.0.12.0). The system has been in successful exploitation on 4 different client servers and has never produced the error I encountered on a new server we setup recently. The exception has occurred only once, upon the initial population with data, and prevented some business entities from being stored to the DB. I really must make sure that in the future the error is properly handled, if not at all possible to be avoided, but am at a loss how. Searching the site and the internet in general for this or similar errors has produced no information. Has any of you encountered this problem or have an idea how to fix it? Thanks :)
Here's the error:
System.NotSupportedException: This stream does not support seek operations.
at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)
at System.IO.BufferedStream.FlushRead()
at System.IO.BufferedStream.WriteByte(Byte value)
at Npgsql.NpgsqlSync.WriteToStream(Stream outputStream)
at Npgsql.NpgsqlReadyState.SyncEnum(NpgsqlConnector context)
at Npgsql.NpgsqlState.Sync(NpgsqlConnector context)
at Npgsql.ForwardsOnlyDataReader.GetNextResponseObject()
at Npgsql.ForwardsOnlyDataReader.GetNextRowDescription()
at Npgsql.ForwardsOnlyDataReader.NextResult()
at Npgsql.ForwardsOnlyDataReader..ctor(IEnumerable`1 dataEnumeration, CommandBehavior behavior, NpgsqlCommand command, NotificationThreadBlock threadBlock, Boolean synchOnReadError)
at Npgsql.NpgsqlCommand.GetReader(CommandBehavior cb)
at Npgsql.NpgsqlCommand.ExecuteNonQuery()
at NHibernate.AdoNet.AbstractBatcher.ExecuteNonQuery(IDbCommand cmd)
at NHibernate.AdoNet.NonBatchingBatcher.AddToBatch(IExpectation expectation)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Boolean[] notNull, Int32 j, SqlCommandInfo sql, Object obj, ISessionImplementor session)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Object obj, ISessionImplementor session)
at NHibernate.Action.EntityInsertAction.Execute()
at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
at NHibernate.Engine.ActionQueue.ExecuteActions()
at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
at NHibernate.Impl.SessionImpl.Flush()
at NHibernate.Transaction.AdoTransaction.Commit()
Since the stack trace originates from NHibernate.Transaction.AdoTransaction.Commit, that means this error was probably logged by NHibernate itself. Your application must do its own logging so that you can have...
details for errors that occur outside of NHibernate
better context for errors that bubble up from NHibernate, like the one you've encountered
See "log all unhandled application errors" and "exception handling should never hide issues" for help on implementing this type of logging.
Without more information about the code that generated this error, this will be nearly impossible to fix. Fixing the logging and exception handling code needs to be one of the top priorities when working with a new code base in order to actually have a fighting chance to fix bugs and improve the code.
This seems to be a bug inside Npgsql.
According to the stacktrace (and checking Npgsql code: https://github.com/npgsql/Npgsql/blob/master/src/Npgsql/NpgsqlDataReader.cs#L1163), when an error occurs inside the GetNextResponseObject(), Npgsql sends a Sync message to server to reset the conversation to a consistent state. The problem is that when this error occurs, some data may have been left in the stream and when Npgsql tries to write to it, the buffered stream checks if there is data yet and, while flushing the data, tries to call seek which isn't supported by a network stream ( over which the buffered stream is created ).
A possible fix for this bug is to flush the buffered stream from any possible data left before writing to it.
I'll create a pull request with this change.
The biggest problem is that this type or error is very rare, as you noticed. This error occurred only once for you. I'll need to investigate more what have caused the exception to be thrown in the first place.
I hope it helps.
The most popular desicion for handling exceptions in rest service and return the error message to client - as i understand - is to catch WebApplicationException or MappableContainerException. But they are extending RuntimeExceprion (I don't understand why). As I know we should avoid handling RuntimeExceptions.
I need to handle such exceptions as "The entity with such name already exsists". I'm sure it is not a runtime exception.
Any other ways? I'm researching now Wrappers. May be you could excplain me the best way to solve my problem?
The way that I handle this is to have my own exception hierarchy, and to build a separate ExceptionMapper which handles this hierarchy. That allows me to pass back whatever information I need to (in my case a JSON-formatted response) in a standardized way.
I would still have an ExceptionMapper for WebApplicationException, otherwise the end user might receive some nasty looking responses. And if you want to be extra-safe then you can also put one in for Exception that picks up anything else you might have missed (the exceptions go to the most specific exception mapper for them, so putting one in for Exception doesn't affect them).
In GWT application I have RPC interface. Some methods works fine (i.e. RemoeServiceServlet configured fine), but when I try to invoke another method, it always fails with onFailure() method. Ajax call also don't occur (I can see it using FireBug, also on server side method invocation don't occur), but another methods of this service performs Ajax calls as well.
When I try to log error using e.getMessage() I get "undefined" message. Also I tried to wrap RPC calling code using try-catch - no error message.
Can this issue be related with GWT-RPC Serialization?
EDIT: Opera Dragonfly showed error on following method inside generated JavaScript (compiled with PRETTY mode):
function $check(this$static, typeSignature){
if (isNull($get_3(this$static.methodMapNative, typeSignature))) {
Unhandled Object: undefined
throw new SerializationException_1(typeSignature);
}
}
with error message
Unhandled Object: undefined
I would guess that you have a Serialization issue, remember that Java Serialization is not the same as GWT Serialization.
There is often no meaningful error message on Serialization errors when using RPC.
must have 0-ary constructor
final fields are inherently transient (ie. do NOT use final fields in classes intended to be serialized)
collections (ex List and Set) must be annotated with #gwt.typeArgs. #gwt.typeArgs is a JavaDoc annotation, thus it must be wrapped in a JavaDoc comment
ex.: /** #gwt.typeArgs */
For more details see:
GWT Serialization
Another thing to try:
When running GWT from the eclipse-plugin, a folder in the eclipse project is created (I belive its called gwt-unitCache). Sometimes my own GWT projects get ill and output strange exceptions, I can solve this by deleting the folder and run the project again.
Trying to understand more about RPCs to answer a homework question: Are exceptions handle the same way for the caller? Are the details of how exceptions are raised on the server any different? Are there any additional differences if you have to rethrow?
OR, can someone just explain what the main differences are between local and remote exceptions? And maybe give an idea of what things to look out for if I wanted to implement remote exceptions.
Here's a simple version of an RPC server / client library:
Server:
try
receive message
deserialize arguments
invoke appropriate method
serialize result
transmit result
catch any Exeption
serialize Exception
transmit Exception
Client (Library code, not the caller):
try
serialize arguments
make remote call
receive "something"
deserialize "something" (could be serialized exception or result)
catch Timeout,Network,Other exceptions not from server
handle whatever the library handles
if deserialized "something" is an exception
rethrow exception from server for caller to catch
else, good/expected results
return results
So, if you want exceptions to be caught by the caller, they possibly differ from regular exceptions in that they must be serialized and transmitted over the network to be re-thrown for the caller.
The caller need not do anything special if the Client library exists. If the client library doesn't exist, then the caller needs to also take the role of the client library. This means that the caller needs to distinguish between serialized results and serialized exceptions (at which point the programmer would probably implement an ad-hoc version of the client library code anyway just to avoid having ugly caller code).
Obviously you can't just use type signatures to distinguish between Exceptions and results (otherwise, what happens if the return type and the exception types for an RPC method were the same?). So there's a tiny bit of overhead in the serialization code for the server to label the different responses.
I am not able to understand the places where an error handling or where an exception handling should be used. I assume this, if it is an existing framework class there are delegate methods which will facilitate the programmer to send an error object reference and handle the error after that. Exception handling is for cases where an operation of a programmer using some framework classes throws an error and i cannot get an fix on the error object's reference.
Is this assumption valid ? or how should i understand them ?
You should use exceptions for errors that would never appear if the programmer would have checked the parameters to the method that throws the exception. E.g. divide by 0 or the well known "out of bounds"-exception you get from NSArrays.
NSErrors are for errors that the programmer could do nothing about. E.g. parsing a plist file. It would be a waste of resources if the program would check if the file is a valid plist before it tries to read its content. For the validity check the program must parse the whole file. And parsing a file to report that it is valid so you can parse it again would be a total waste. So the method returns a NSError (or just nil, which tells you that something went wrong) if the file can't be parsed.
The parsing for validity is the "programmer should have checked the parameters" part. It's not applicable for this type of errors, so you don't throw a exception.
In theory you could replace the out of bounds exception with a return nil. But this would lead to very bad programming.
Apple says:
Important: In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object.
I think you are absolutely right with your assumption for Errors and for it framework provide a set of methods (UIWebView error handling ), But your assumption for Exception partially right because the exception only occurred if we do something wrong which is not allowed by the framework and can be fixed. (for example accessing a member from an array beyond its limit).
and will result in application crash.