Yeah, this is a tradeoff I'm still struggling with. The problem is tha=
t
there are three different API's, and each language has its own set of
standards. So the question is, it it more important to follow the
conventions each language, or to keep all the API's consistent among
themselves. If I am maintaining C++ and Java applications that use QF,=
I'd
like those two API's to be as similar as possible. This is certainly a=
n
important issue for consultants who may need to implement FIX applicati=
ons
for different clients with different language requirements. Unfortunat=
ely,
C++/Java/.NET have different conventions.
It's an odd situation, because in C++ you don't really throw exceptions=
,
you throw types (int, string, std::exception, whatever the hell you wan=
t).
Since java has the strictest requirements, it may make sense to use tho=
se
and adopt them in the other API's.
--oren
|---------+----------------------------------------------->
| | Joerg Thoennes |
| | <Joe...@ma...> |
| | Sent by: |
| | qui...@li...ur|
| | ceforge.net |
| | |
| | |
| | 04/10/2003 12:42 PM |
| | Please respond to Joerg.Thoennes |
| | |
|---------+----------------------------------------------->
>--------------------------------------------------------------------=
--------------------------|
| =
|
| To: Mike Hepburn <mi...@an...> =
|
| cc: quickfix <qui...@li...=
> |
| Subject: Re: [Quickfix-developers] problems with quickfix-1.=
4.1 - Java code |
>--------------------------------------------------------------------=
--------------------------|
> (1) trying to (java) compile an application that cracks FIX4.3 messag=
es
> (in Java) with quickfix 1.4.1 is slightly broken due to some missing
> throw specifiers in the socket initiator/acceptor classes (see Socket=
> Acceptor, Initiator diff's below)
Regarding exception names: Java has a naming standard here, and it woul=
d be
nice if
QuickFIX could also adhere to this standard:
- Checked exceptions extend java.lang.Exception and must be specified i=
n
the throws clause.
They are named XyzException. They should be used in all cases where =
the
programmer could
deal with the problem indicated, eg just retry or try some other way=
.
- Unchecked exceptions extend java.lang.RuntimeException and can be lef=
t
out of the throws
clause. They normally indicate programming errors
(ArrayOutOfBoundsException etc.) and
the programmer is not expected to do any useful recovery. The progra=
m
should terminate.
- Errors extend java.lang.Error and indicate fatal runtime errors:
"An Error is a subclass of Throwable that indicates serious problems=
that a reasonable application should not try to catch. Most such er=
rors
are abnormal conditions."
Examples are OutOfMemoryError, StackOverFlowError etc.
It would be good if the exception naming of QuickFIX could reflect this=
,
e.g. the ConfigError
should be changed to the ConfigException, the UnsupportedMessageType to=
UnsupportedMessageTypeException.
OK, this is a major change, but would make the API more consistent.
Cheers, J=F6rg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger
for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd
disoriented. TotalView can help you find your way. Available on major U=
NIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
=
|
