Stubbing the rest of JSR 075 (PIM) #154
Conversation
I didn't find anything that needs this yet, but since it is part of the ME specification, it's good to have it around just in case.
Not that necessary, but it gets that class closer to the docs.
There was a problem hiding this comment.
You could probably have broken this up into multiple requests rather than one big omnibus. It makes review a bit more error prone as people tend to skip over details when there's a lot to go over.
I understand wanting to push it in one big block because that's how you wrote it, but it does get tiring.
| public class FieldFullException extends RuntimeException | ||
| { | ||
|
|
||
| private final int fieldVal; |
There was a problem hiding this comment.
I was trying to optimize those exceptions by only allowing one assignment into that fieldVal int var. My logic at the time i was writing those classes was that if the Java app will throw new exception object every time it happens, it wouldn't be harmful to have that field as final... but better be on the safe side and allow it to be assigned as much as it needs to be.
| public FieldFullException(String detailMessage, int field) | ||
| { | ||
| super(detailMessage); | ||
| this.fieldVal = field; |
There was a problem hiding this comment.
this isn't necessary. See line 29.
You sometimes see this used when the field and parameter share the same name, which they do not. I typically favor modifying the name of the parameter rather than using this to avoid any potential confusion.
There was a problem hiding this comment.
Hmm... i've been stubbing those files for a few days so i don't remember exactly why things like those are in, but i named it "field" at the start and figured it would be better to just give it a unique name in the class, but probably didn't alter the rest of the code. I'll be removing those from all the files with unique fields i can find.
JSR 075 is composed of both FileConnect and PIM. FileConnect is being reviewed alongside bluetooth and obex over at #145, and adding even more files to that massive pull request isn't a good idea. Thankfully, PIM has no dependency on FileConnect, so it can be its own PR.
Fixes #155.
Edit: I see, yes i could have separated it into smaller units, but i figured having the whole PIM spec in one PR would be more organized. I'll try shortening the amount of files and changes in the next pull requests.