[
https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986996#action_12986996
]
Gary Gregory commented on CODEC-95:
-----------------------------------
My preference would be to stop growing the API with ctors for optional
attributes: The ctors for this class builds objects with parameters that are
required (if any as defined by the RFC), thats's it . Exceptions are be made
for common options. Perhaps line length and EOL are such common settings, you
mileage may vary. I never change those.
For optional and non-standard (per the RFC) settings, the values are set via
setters.
No need for config objects, IMO, which end up feeling more like structs and
feel less OO, less thought out: oh let's hide all this and dump it in a config
object.
If it makes sense for the impl or OO design we can have subclass like
Base64StrictInputStream that carries the extra settings and logic. Otherwise,
we can leave it all in one class.
> Base64: optionally allow strict parsing of base64 strings
> ---------------------------------------------------------
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Adam Rabung
> Priority: Minor
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode
> table. I realize this is perfectly to spec, but I wonder if other users
> might appreciate a "strict" mode that throws an exception when one of these
> illegal characters are encountered. For example, I would love an exception
> to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
