Re: HTTP2 parsing and error handling
On 09/06/2015 11:31, Rémy Maucherat wrote: 2015-06-09 11:53 GMT+02:00 Konstantin Kolinko knst.koli...@gmail.com: 2015-06-08 15:37 GMT+03:00 Mark Thomas ma...@apache.org: All, I'm not particularly happy with the current error handling (based around Http2Exception) and as I work my way through the spec in detail I am coming across cases that are becoming increasingly difficult to handle cleanly. I think I have reached the point where a completely different approach is needed. I am thinking along the lines of a ParseState object that gets passed around and updated if things go wrong. I'm going to try this approach over the next few days. If it works there is likely to be a largish commit to switch to this new approach but I'll try and keep that commit limited to changing the error handling. +1 One bonus from a flag vs. an exception is that it can be sticky. I mean a situation like one fixed by this commit: http://svn.apache.org/r1600984 Yes, and then it doesn't get properly recycled :) That aside, flags are often good. I managed to clean things up and make progress without such a large refactoring. I haven't finished implementing all the checks yet so I may still come back to this approach if the code starts to get messy again. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: HTTP2 parsing and error handling
2015-06-08 15:37 GMT+03:00 Mark Thomas ma...@apache.org: All, I'm not particularly happy with the current error handling (based around Http2Exception) and as I work my way through the spec in detail I am coming across cases that are becoming increasingly difficult to handle cleanly. I think I have reached the point where a completely different approach is needed. I am thinking along the lines of a ParseState object that gets passed around and updated if things go wrong. I'm going to try this approach over the next few days. If it works there is likely to be a largish commit to switch to this new approach but I'll try and keep that commit limited to changing the error handling. +1 One bonus from a flag vs. an exception is that it can be sticky. I mean a situation like one fixed by this commit: http://svn.apache.org/r1600984 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: HTTP2 parsing and error handling
2015-06-09 11:53 GMT+02:00 Konstantin Kolinko knst.koli...@gmail.com: 2015-06-08 15:37 GMT+03:00 Mark Thomas ma...@apache.org: All, I'm not particularly happy with the current error handling (based around Http2Exception) and as I work my way through the spec in detail I am coming across cases that are becoming increasingly difficult to handle cleanly. I think I have reached the point where a completely different approach is needed. I am thinking along the lines of a ParseState object that gets passed around and updated if things go wrong. I'm going to try this approach over the next few days. If it works there is likely to be a largish commit to switch to this new approach but I'll try and keep that commit limited to changing the error handling. +1 One bonus from a flag vs. an exception is that it can be sticky. I mean a situation like one fixed by this commit: http://svn.apache.org/r1600984 Yes, and then it doesn't get properly recycled :) That aside, flags are often good. Rémy
HTTP2 parsing and error handling
All, I'm not particularly happy with the current error handling (based around Http2Exception) and as I work my way through the spec in detail I am coming across cases that are becoming increasingly difficult to handle cleanly. I think I have reached the point where a completely different approach is needed. I am thinking along the lines of a ParseState object that gets passed around and updated if things go wrong. I'm going to try this approach over the next few days. If it works there is likely to be a largish commit to switch to this new approach but I'll try and keep that commit limited to changing the error handling. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
