Standard exceptions for an RPC library?
-
Current targets are: .NET (C# and VB.net mainly) C++ (boost::exception) Python Java MATLAB Octave SciLab Perl ActionScript Possible targets are PHP TCL None of them have common exception types.
The usual way round this is to have your library provide core functionality, and its own set of internal exceptions. You then add a wrapper for each language which maps method/function calls and internal library data to the types required by the language. [edit] Alternatively, forget about exceptions and just use return codes to indicate success or failure of client requests. XML offers many possible ways of achieving this. [/edit]
One of these days I'm going to think of a really clever signature.
-
Current targets are: .NET (C# and VB.net mainly) C++ (boost::exception) Python Java MATLAB Octave SciLab Perl ActionScript Possible targets are PHP TCL None of them have common exception types.
johndw94 wrote:
None of them have common exception types.
Correct, and there's no standard or default. What are you trying to achieve? Building a "unified" store for all application-exceptions? It'd be more appropriate to use an issue-tracker, so that's probably not it.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
The usual way round this is to have your library provide core functionality, and its own set of internal exceptions. You then add a wrapper for each language which maps method/function calls and internal library data to the types required by the language. [edit] Alternatively, forget about exceptions and just use return codes to indicate success or failure of client requests. XML offers many possible ways of achieving this. [/edit]
One of these days I'm going to think of a really clever signature.
My question was WHICH exceptions to wrap. I already implemented the rest of these comments a long time ago...
-
johndw94 wrote:
None of them have common exception types.
Correct, and there's no standard or default. What are you trying to achieve? Building a "unified" store for all application-exceptions? It'd be more appropriate to use an issue-tracker, so that's probably not it.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
No, the objective is to pass them back to the client. For instance, FileNotFoundException would be passed back to the client if the server couldn't find a file. Unfortunately in C# this would be System.IO.FileNotFoundException, while in python it would be IOError meaning that python will not have any idea what the C# exception is. There are a huge number of exceptions defined in many languages. What do you think are the most "common" or "important"?
-
No, the objective is to pass them back to the client. For instance, FileNotFoundException would be passed back to the client if the server couldn't find a file. Unfortunately in C# this would be System.IO.FileNotFoundException, while in python it would be IOError meaning that python will not have any idea what the C# exception is. There are a huge number of exceptions defined in many languages. What do you think are the most "common" or "important"?
That sounds like an overarchitecture; exceptions are handled locally by the client, by the language-mechanism that they're created in. Next, you aggregate abstractions to a server. Your architecture only makes sense if the FileNotFoundException would be handled using PHP when it returns. Again, all exceptions are important. Can you describe the current exception-handling strategy employed?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
That sounds like an overarchitecture; exceptions are handled locally by the client, by the language-mechanism that they're created in. Next, you aggregate abstractions to a server. Your architecture only makes sense if the FileNotFoundException would be handled using PHP when it returns. Again, all exceptions are important. Can you describe the current exception-handling strategy employed?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
You can take a look at the project: http://robotraconteur.net. I have not been publicizing it because the API is still in flux. I don't want to have too many people adopt it and then immediately change the API. Right now the "primary" language is C#. It is the language I am most comfortable with, and have been propagating the changes to other languages. Exceptions are handled by catching any exceptions on the service, saving the exception name and message, and passing the information across the boundary. A container exception is then throw (RobotRaconteurRemoteException) containing the name and message (similar to Java RMI exception handling). A set of built-in exceptions are handled differently that throw a more detailed exception class. You can see the error code in Error.cs. The problem is that the exception names are language-specific, and if someone decides to write a service in a different language the exception names will be different, leading to an annoying design for the clients.
-
My question was WHICH exceptions to wrap. I already implemented the rest of these comments a long time ago...
All of them, obviously. There is little point in writing a library that provides communication like .NET remoting or SOAP but is far more flexible in terms of supported languages and platforms, unless it can handle all types, which is, after all, what you claim to be doing.
One of these days I'm going to think of a really clever signature.
-
All of them, obviously. There is little point in writing a library that provides communication like .NET remoting or SOAP but is far more flexible in terms of supported languages and platforms, unless it can handle all types, which is, after all, what you claim to be doing.
One of these days I'm going to think of a really clever signature.
Yes, all exceptions are already passed back. They just don't have a common name. Passing the name of a C# exception to a Python program won't help much .There are a core set of exceptions that should be handled in a neutral manner. The question is, what are those core exceptions?
-
Yes, all exceptions are already passed back. They just don't have a common name. Passing the name of a C# exception to a Python program won't help much .There are a core set of exceptions that should be handled in a neutral manner. The question is, what are those core exceptions?
axpnumtheory wrote:
The question is, what are those core exceptions?
The only way such a question could be answered is to list every exception from every language that you plan to support and exclude any that are not common. I have no idea whether such a list has already been created by anyone else.
One of these days I'm going to think of a really clever signature.
-
You can take a look at the project: http://robotraconteur.net. I have not been publicizing it because the API is still in flux. I don't want to have too many people adopt it and then immediately change the API. Right now the "primary" language is C#. It is the language I am most comfortable with, and have been propagating the changes to other languages. Exceptions are handled by catching any exceptions on the service, saving the exception name and message, and passing the information across the boundary. A container exception is then throw (RobotRaconteurRemoteException) containing the name and message (similar to Java RMI exception handling). A set of built-in exceptions are handled differently that throw a more detailed exception class. You can see the error code in Error.cs. The problem is that the exception names are language-specific, and if someone decides to write a service in a different language the exception names will be different, leading to an annoying design for the clients.
There is no such thing as a common set of errors. The concept does not exist. To make matters worse, people also create their own exceptions. You can generalize them to a degree, but you can't generalize a solution. That's something that's not only language-specific,.but also platform dependent and even depends on the users' rights. The FileNotFoundException might be uninteresting, or jeopordizing five years worth of data. It might be that I forgot to log on to the remote directory (in which case I'd like to be informed with a message) or I might be a hacker, poking around. I don't understand what you're trying to achieve, even after reading the introduction.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
All, I am writing a library that provides communication like .NET remoting or SOAP but is far more flexible in terms of supported languages and platforms. Part of the program involves transmitting exceptions across the boundary between the connected programs. Because it runs on several languages, there isn't really a standard set of exceptions. What exceptions do you think are important? I am curious what the general community thinks.
Thread is getting confused so I am going to rephrase to what I think has been said. You have a communications library/protocol. You want to allow 'exceptions' to the 'thrown' via that. And you want to support many languages. That means your library MUST have the following components. 1. A server component. 2. A client component. In terms of generality 1 and 2 can be different programming languages withing the same enterprise. So that means that you MUST do the following. A. Create your OWN protocol method for transmitting an 'exception'. Note that this does NOT mean nor can it mean that you use a language specific exception. Your protocol must NOT use any such exception. B. Implement your protocol (1) such that is has some common idioms for supporting communication errors. It does that because communication errors are the only common error type that such a library intrinsically knows about. C. Optionally you provide a way for an implementer to 'extend' your protocol to add their own 'exception' (again this will NOT be a language specific exception.) AFTER you complete the above then you do the following. 1. Implement your library server code for a specific language so that it catches ALL language specific exceptions. And then it converts them into your protocol as defined above. That and only that is what is sent to the client library. 2. Implement your client library for a specific language so that it receives the protocol 'exception' and translates it into an appropriate language specific exception. AFTER you have complete all of the above if you have and specific exceptions for specific languages that you want to implement then you use C above to modify the specific library components, perhaps only on the server side but perhaps both sides as well. If you are clever then you will find that there are ways to define A such that you can use a configuration (rather than code) to add in new language exceptions both in the server and client.
-
Thread is getting confused so I am going to rephrase to what I think has been said. You have a communications library/protocol. You want to allow 'exceptions' to the 'thrown' via that. And you want to support many languages. That means your library MUST have the following components. 1. A server component. 2. A client component. In terms of generality 1 and 2 can be different programming languages withing the same enterprise. So that means that you MUST do the following. A. Create your OWN protocol method for transmitting an 'exception'. Note that this does NOT mean nor can it mean that you use a language specific exception. Your protocol must NOT use any such exception. B. Implement your protocol (1) such that is has some common idioms for supporting communication errors. It does that because communication errors are the only common error type that such a library intrinsically knows about. C. Optionally you provide a way for an implementer to 'extend' your protocol to add their own 'exception' (again this will NOT be a language specific exception.) AFTER you complete the above then you do the following. 1. Implement your library server code for a specific language so that it catches ALL language specific exceptions. And then it converts them into your protocol as defined above. That and only that is what is sent to the client library. 2. Implement your client library for a specific language so that it receives the protocol 'exception' and translates it into an appropriate language specific exception. AFTER you have complete all of the above if you have and specific exceptions for specific languages that you want to implement then you use C above to modify the specific library components, perhaps only on the server side but perhaps both sides as well. If you are clever then you will find that there are ways to define A such that you can use a configuration (rather than code) to add in new language exceptions both in the server and client.