Design and Architecture
|
|
 |
|
Yes, all exceptions are already passed back to the client but the exception names are not standard across different languages. I am trying to come up with a table that will be translated to language-native exceptions.
|
|
|
|
|
johndw94 wrote: the exception names are not standard across different languages
Can you clarify "different languages"?
Different in .NET? The classname of an IndexOutOfRangeException[^] is the same for each .NET language.
Different across all computer-languages, thus including the TIndexOutOfRangeException[^]? In that case, limit yourself to the exceptions that have already been reported.
Different across human languages? Try unlocalize.com[^]
Logging of exception-text in the English language? Set the culture to English when you ToString. You should be able to build that table for .NET by enumerating all the classes that inherit from Exception, using Reflection.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
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"?
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin
Submit an article or tip
Post your Blog
