[
https://issues.apache.org/jira/browse/SAMZA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155350#comment-14155350
]
Jonathan Herriott commented on SAMZA-427:
-----------------------------------------
I guess we have a complete disagreement on exceptions then :P
My problem with Using RuntimeExceptions is that it can suppress actual issues
that can and should be caught in development. I would also agree about using
"throws Exception" being bad as well since it is too generic. There does exist
a SamzaException, however, there is no contractual obligation of the developer
to even use that exception or even knowing that it is handled by the caller of
the method. The throws itself can and should be documented stating what
happens when a possible exception is thrown.
I guess the feature I'd like out of this is the ability to say "skip this
message on failure", however, I don't think it should be the job of SerDe to
decide whether to skip the message. I would be okay with returning null if
there is no way that null can be a valid response, however, this makes it so no
information may be passed out of it other than "it failed", so I would be
unable to answer the question of "why did this fail"? Exceptions in this case
are a convenience in that I can stuff all necessary data into them. This is
with 100% the idea that the logging of a "failed message" is a pluggable thing
that doesn't need to be associated with any particular SerDe.
Right now, if a RuntimeException were to happen, my expectation is that the
entire process would barf, which may or may not be true. The reason I dislike
this is it is pulling messages from Kafka, and can you fully control what gets
put into Kafka in an organization with a lot of developers? In general, I'd
expect that upon receiving a message it can't decode, it would log that message
somewhere and return back to the caller saying it can't be decoded, so the
caller can continue if it chooses (in development, I'd probably say it
shouldn't continue, but in production, it should and so should be configurable
by the developer). Right now, I have no idea what would happen if I just
returned null based on the documentation of the deserializer:
http://samza.incubator.apache.org/learn/documentation/0.7.0/api/javadocs/org/apache/samza/serializers/Deserializer.html
Mind you, I've been trying to find all the code, but I can't find what is the
caller of these interfaces.
In terms of backwards compatibility, I don't know off the top of my head
whether the actual method signatures would change for already compiled code. I
believe, based off of my JNI experience, old jars would still run with newer
framework, however, if they wanted to recompile with a newer framework, they'd
have to include the "throws", which I would believe is acceptable.
> Serializer and Decoder Interfaces Should Be able to raise Exceptions
> --------------------------------------------------------------------
>
> Key: SAMZA-427
> URL: https://issues.apache.org/jira/browse/SAMZA-427
> Project: Samza
> Issue Type: Bug
> Reporter: Jonathan Herriott
> Labels: newbie
> Fix For: 0.8.0
>
>
> Right now, both interfaces expect that an exception cannot be thrown. The
> issue I have with this is that if a message is received that cannot be
> properly decoded (something else wrote a bad message to the same topic) or if
> implementing an Avro Serde with an Avro Schema Repository Support, which
> could potentially not even have the schema registered (shouldn't happen, but
> still need to be able to handle in case it does).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
