Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Andrea Aime wrote:
Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,48652f67254873362379201!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Meh... I'd still like to log the exception in English, and have
a way to gather a message useful enough for reporting in
the UI. The way gt2 does it logs the messages transalated.
Now, I'm not sure I would be happy to receive a stacktrace
from a users's log in Thai 
As for a wicket way, I don't know... but I don't believe there
is one. I'll look into it, yet so far it seems the viable way is
still to attach a generic key and param inside the exceptions
that we know we'll need to use for error reporting in the UI?
interface LocalizableException {
String getKey();
Object getParams();
}
Generally speaking a normal exception would do, it's just that
in this auto configure case many things may go wrong. I can
create a set of exception subclasses of course, and avoid messing
with the rest of the code.
Cheers
Andrea
I'm not sure doing this directly at the level of exceptions is exactly what we should be doing here. If we want to report some potential problems but continue the operation as normal then exceptions don't really model what we want to do very well. I am thinking we do something like
public static class ResourceUtilities {
public static class Report{
public ReportStatus getSeverity(); // Some indication of how critical the problem was
public String getMessage(Locale locale); // A description of what went wrong, readable to users in (locale)
}
public static class ConfigurationException extends Exception{
public List<Report> getReports();
}
public List<Report> autoConfigure(Catalog catalog, ResourceInfo resource, String layerName); // or whatever parameters make sense for the autoconfiguration operation
}
This would let us have error messages accessible when things are recoverable, but access them all when there's an exception as well. We could possibly have a Report with status == Report.SUCCESS that wraps up any associated data needed (like the resulting configured layer, for example).
-David
Justin Deoliveira wrote:
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Andrea Aime wrote:
Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Meh... I'd still like to log the exception in English, and have
a way to gather a message useful enough for reporting in
the UI. The way gt2 does it logs the messages transalated.
Now, I'm not sure I would be happy to receive a stacktrace
from a users's log in Thai
Right :). Good point.
As for a wicket way, I don't know... but I don't believe there
is one. I'll look into it, yet so far it seems the viable way is
still to attach a generic key and param inside the exceptions
that we know we'll need to use for error reporting in the UI?
interface LocalizableException {
String getKey();
Object getParams();
}
I could go for this. I guess under the covers it would run through the GeoServer i18n process to resolve the key to an error message? If so then perhaps we should break out an exception for ui purposes. Something like:
class WebException extends Exception (or RuntimeException?) {
WebException(GeoServerApplication app, String key);
WebException(GeoServerApplication app, String key, Object params );
...
}
Generally speaking a normal exception would do, it's just that
in this auto configure case many things may go wrong. I can
create a set of exception subclasses of course, and avoid messing
with the rest of the code.
Cheers
Andrea
!DSPAM:4007,48653410267535409313003!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
This is an interesting idea. I like it although I wonder if we could just use the wicket Feedback stuff rather than break out our own. At first glance the FeedbackMessage class seems to embody this same functionality.
David Winslow wrote:
I'm not sure doing this directly at the level of exceptions is exactly what we should be doing here. If we want to report some potential problems but continue the operation as normal then exceptions don't really model what we want to do very well. I am thinking we do something like
public static class ResourceUtilities {
public static class Report{
public ReportStatus getSeverity(); // Some indication of how critical the problem was
public String getMessage(Locale locale); // A description of what went wrong, readable to users in (locale)
}
public static class ConfigurationException extends Exception{
public List<Report> getReports();
}
public List<Report> autoConfigure(Catalog catalog, ResourceInfo resource, String layerName); // or whatever parameters make sense for the autoconfiguration operation
}
This would let us have error messages accessible when things are recoverable, but access them all when there's an exception as well. We could possibly have a Report with status == Report.SUCCESS that wraps up any associated data needed (like the resulting configured layer, for example).
-David
Justin Deoliveira wrote:
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Andrea Aime wrote:
Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,48653512270431637810514!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Does using the wicket feedback system tie us to only doing configuration in a Wicket UI? There are other places (well, RESTConfig is pretty much it at the moment) where autoconfiguration could be useful. Also, it feels a little icky having the Catalog tied to the UI this way. An adapter would be great of course.
(Disclaimer: the FeedbackMessage stuff is one of many parts of Wicket I haven't really looked at yet)
-David
Justin Deoliveira wrote:
This is an interesting idea. I like it although I wonder if we could just use the wicket Feedback stuff rather than break out our own. At first glance the FeedbackMessage class seems to embody this same functionality.
David Winslow wrote:
I'm not sure doing this directly at the level of exceptions is exactly what we should be doing here. If we want to report some potential problems but continue the operation as normal then exceptions don't really model what we want to do very well. I am thinking we do something like
public static class ResourceUtilities {
public static class Report{
public ReportStatus getSeverity(); // Some indication of how critical the problem was
public String getMessage(Locale locale); // A description of what went wrong, readable to users in (locale)
}
public static class ConfigurationException extends Exception{
public List<Report> getReports();
}
public List<Report> autoConfigure(Catalog catalog, ResourceInfo resource, String layerName); // or whatever parameters make sense for the autoconfiguration operation
}
This would let us have error messages accessible when things are recoverable, but access them all when there's an exception as well. We could possibly have a Report with status == Report.SUCCESS that wraps up any associated data needed (like the resulting configured layer, for example).
-David
Justin Deoliveira wrote:
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Andrea Aime wrote:
Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Right... i was just talking in terms of UI. I am not sure we want to tackle this sort of scheme outside of the context of the web interface. I mean i don't think it makes sense for the catalog or some other internal subsystem to determine if a failed operation was "severe" or not... i think only the calling code (the ui) can make that decision.
However that still leaves us with the initial problem of localizing exception messages... I am curious to figure out how other web applications / servers tackle this problem. Do they:
1. Not localize exception messages which originate from "lower levels" of the application
or
2. Come up with an interface similar to what Andrea suggested
or
3. Something else
David Winslow wrote:
Does using the wicket feedback system tie us to only doing configuration in a Wicket UI? There are other places (well, RESTConfig is pretty much it at the moment) where autoconfiguration could be useful. Also, it feels a little icky having the Catalog tied to the UI this way. An adapter would be great of course.
(Disclaimer: the FeedbackMessage stuff is one of many parts of Wicket I haven't really looked at yet)
-David
Justin Deoliveira wrote:
This is an interesting idea. I like it although I wonder if we could just use the wicket Feedback stuff rather than break out our own. At first glance the FeedbackMessage class seems to embody this same functionality.
David Winslow wrote:
I'm not sure doing this directly at the level of exceptions is exactly what we should be doing here. If we want to report some potential problems but continue the operation as normal then exceptions don't really model what we want to do very well. I am thinking we do something like
public static class ResourceUtilities {
public static class Report{
public ReportStatus getSeverity(); // Some indication of how critical the problem was
public String getMessage(Locale locale); // A description of what went wrong, readable to users in (locale)
}
public static class ConfigurationException extends Exception{
public List<Report> getReports();
}
public List<Report> autoConfigure(Catalog catalog, ResourceInfo resource, String layerName); // or whatever parameters make sense for the autoconfiguration operation
}
This would let us have error messages accessible when things are recoverable, but access them all when there's an exception as well. We could possibly have a Report with status == Report.SUCCESS that wraps up any associated data needed (like the resulting configured layer, for example).
-David
Justin Deoliveira wrote:
Hmmm... good question. Is there any standard wicket way for i18n'ing exception messages? Also what does Geotools do. It uses resources bundles for exception messages like wicket does, perhaps the two might be compatible?
Andrea Aime wrote:
Hi,
I'm working on some code that should auto configure a
feature type or a coverage. The code can fail for a number
or reasons, and should be usable for both REST and the
web UI.
The thing is, for REST an exception in english probably
does the trick, but for the web UI we want to report
the user why the auto-configuration failed, which means
simply thorwing an exception does not cut it... or else,
it might, but we'd need to be able and get an i18n key
as well as its eventual parameters (complex messages might
need MessageFormat like parametrization).
On the same line we might want to report back warnings,
stuff like "I could not figure out what the heck this
CRS is, so I kept it and forced an on the fly reprojection
to 4326 for data publishing".
Now for the warnings the thing could be that the auto
configure method does not return a simple result, but
returns an "auto configuration processor" that allows
you to call auto-configure and get back the resource,
and then call for warnings.
I could do the same for exceptions in this case, return
null from the main path and have a method that returns
the error messages.
But... I'm more interested in seeing if we can come
up with a general solution, since this problem
might come up in other situations as well.
Is it a good idea to add the exceptions a getKey()
and getParam() -> Object methods. Should we come
up with something able to turn an exception into
a localized message instead (pluggable tranformer)?
Or do you feel I'm just overdoing this, and we should
just report back the user it's not his lucky day
without details on the why?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,48653b1f286193327367457!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
On Friday 27 June 2008 09:35:08 pm Justin Deoliveira wrote:
Right... i was just talking in terms of UI. I am not sure we want to
tackle this sort of scheme outside of the context of the web interface.
I mean i don't think it makes sense for the catalog or some other
internal subsystem to determine if a failed operation was "severe" or
not... i think only the calling code (the ui) can make that decision.
However that still leaves us with the initial problem of localizing
exception messages... I am curious to figure out how other web
applications / servers tackle this problem. Do they:
1. Not localize exception messages which originate from "lower levels"
of the application
or
2. Come up with an interface similar to what Andrea suggested
or
3. Something else
I'm sure others do it by defining well known error codes for well known
exception messages.
For instance, the ArcSDE Java API has SeException which in turn has
SeException.getSeError():SeError
and SeError defines the error constants
<http://edndoc.esri.com/arcsde/9.1/java_api/docs/com/esri/sde/sdk/client/seerror.html>
we could do something similar, ie, either having our own exception which
overrides getLocalizedMessage() or that defines getMessage(Locale):String,
depending on what we want to achieve. Then we could decide if we want the
message in the stack trace to be always in english or we could anyway figure
out what the problem is by the error code in the stack trace message.
my 2c.
Gabriel
David Winslow wrote:
> Does using the wicket feedback system tie us to only doing configuration
> in a Wicket UI? There are other places (well, RESTConfig is pretty much
> it at the moment) where autoconfiguration could be useful. Also, it
> feels a little icky having the Catalog tied to the UI this way. An
> adapter would be great of course.
>
> (Disclaimer: the FeedbackMessage stuff is one of many parts of Wicket I
> haven't really looked at yet)
>
> -David
>
> Justin Deoliveira wrote:
>> This is an interesting idea. I like it although I wonder if we could
>> just use the wicket Feedback stuff rather than break out our own. At
>> first glance the FeedbackMessage class seems to embody this same
>> functionality.
>>
>> David Winslow wrote:
>>> I'm not sure doing this directly at the level of exceptions is
>>> exactly what we should be doing here. If we want to report some
>>> potential problems but continue the operation as normal then
>>> exceptions don't really model what we want to do very well. I am
>>> thinking we do something like
>>>
>>> public static class ResourceUtilities {
>>> public static class Report{
>>> public ReportStatus getSeverity(); // Some indication of how
>>> critical the problem was
>>> public String getMessage(Locale locale); // A description of
>>> what went wrong, readable to users in (locale)
>>> }
>>>
>>> public static class ConfigurationException extends Exception{
>>> public List<Report> getReports();
>>> }
>>>
>>> public List<Report> autoConfigure(Catalog catalog, ResourceInfo
>>> resource, String layerName); // or whatever parameters make sense for
>>> the autoconfiguration operation
>>> }
>>>
>>> This would let us have error messages accessible when things are
>>> recoverable, but access them all when there's an exception as well.
>>> We could possibly have a Report with status == Report.SUCCESS that
>>> wraps up any associated data needed (like the resulting configured
>>> layer, for example).
>>>
>>> -David
>>>
>>> Justin Deoliveira wrote:
>>>> Hmmm... good question. Is there any standard wicket way for i18n'ing
>>>> exception messages? Also what does Geotools do. It uses resources
>>>> bundles for exception messages like wicket does, perhaps the two
>>>> might be compatible?
>>>>
>>>> Andrea Aime wrote:
>>>>> Hi,
>>>>> I'm working on some code that should auto configure a
>>>>> feature type or a coverage. The code can fail for a number
>>>>> or reasons, and should be usable for both REST and the
>>>>> web UI.
>>>>>
>>>>> The thing is, for REST an exception in english probably
>>>>> does the trick, but for the web UI we want to report
>>>>> the user why the auto-configuration failed, which means
>>>>> simply thorwing an exception does not cut it... or else,
>>>>> it might, but we'd need to be able and get an i18n key
>>>>> as well as its eventual parameters (complex messages might
>>>>> need MessageFormat like parametrization).
>>>>>
>>>>> On the same line we might want to report back warnings,
>>>>> stuff like "I could not figure out what the heck this
>>>>> CRS is, so I kept it and forced an on the fly reprojection
>>>>> to 4326 for data publishing".
>>>>>
>>>>> Now for the warnings the thing could be that the auto
>>>>> configure method does not return a simple result, but
>>>>> returns an "auto configuration processor" that allows
>>>>> you to call auto-configure and get back the resource,
>>>>> and then call for warnings.
>>>>>
>>>>> I could do the same for exceptions in this case, return
>>>>> null from the main path and have a method that returns
>>>>> the error messages.
>>>>>
>>>>> But... I'm more interested in seeing if we can come
>>>>> up with a general solution, since this problem
>>>>> might come up in other situations as well.
>>>>> Is it a good idea to add the exceptions a getKey()
>>>>> and getParam() -> Object methods. Should we come
>>>>> up with something able to turn an exception into
>>>>> a localized message instead (pluggable tranformer)?
>>>>>
>>>>> Or do you feel I'm just overdoing this, and we should
>>>>> just report back the user it's not his lucky day
>>>>> without details on the why?
>>>>>
>>>>> Cheers
>>>>> Andrea
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>----
>>>>>
>>>>> Check out the new SourceForge.net Marketplace.
>>>>> It's the best place to buy or sell services for
>>>>> just about anything Open Source.
>>>>> http://sourceforge.net/services/buy/index.php
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> Geoserver-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldán ha scritto:
...
I'm sure others do it by defining well known error codes for well known exception messages.
For instance, the ArcSDE Java API has SeException which in turn has SeException.getSeError():SeError
and SeError defines the error constants <http://edndoc.esri.com/arcsde/9.1/java_api/docs/com/esri/sde/sdk/client/seerror.html>
Cool, this works fine, but we have to accept a limitation with parametrized messages (the ones that want to report, for example,
the name of the datastore that failed, or the WKT of the srs code that was not recognized), which is, we either do not parametrize the error
messages at all, or we do so using only the objects that the caller
can see (such as, for example, "layer X could not be auto configured" because the feature type name is a known item in the context of the
caller.
we could do something similar, ie, either having our own exception which overrides getLocalizedMessage() or that defines getMessage(Locale):String, depending on what we want to achieve. Then we could decide if we want the message in the stack trace to be always in english or we could anyway figure out what the problem is by the error code in the stack trace message.
The issue I'm seeing here is that localized exceptions would use a parallel i18n system, not the one used by wicket. Since we don't really
need to parametrize the error messages for REST return values (I'm still
solidly convinced a programming API using only english is good enough,
other may have a different opinion), and that the i18n subsystem is Wicket specific (we don't want it to taint the other modules, right?)
I'd say the above approach (error codes) is good enough, and that if
we need more, we can roll subclasses that do provide the parameters
as fields of the exception.
Seems like a good approach to me, if nobody objects, I'll follow it.
Maybe using enums instead of integer contants 
Cheers
Andrea