Thanks for your response Jason and Geert.. I think the underlying point is to use try catches judiciously and then think about performance by using query meter.
On Fri, May 6, 2011 at 12:11 AM, Jason Hunter <[email protected]> wrote: > If there's any background executions happening inside the try block (a > cts:element-values call for example, or an xdmp:http-get) they have to be > finished before exiting the try block. Because if they error out, the error > has to be handled in the catch. > > Geert's advice is spot-on. Write the appropriate code for your needs. > This is pretty advanced stuff that you shouldn't have to worry about except > in rare circumstances. > > (What's pretty cool is how much background thread execution is happening > without you ever realizing it.) > > -jh- > > On May 5, 2011, at 12:34 PM, Geert Josten wrote: > > Hi Abishek, > > You were probably triggered by the phrase ‘the block must be completely > evaluated before the server can move on’. I’m not familiar with the > internals of MarkLogic Server, but there is nothing against processing the > contents of the try block in parallel threads (provided the code in the > block is suitable for it).. > > In the end there is only one real way to know what makes true difference: > measure it. I recommend writing some real scenario’s and run them against > MarkLogic Server using performance-meters. ( > http://developer.marklogic.com/code/performance-meters) > > Kind regards, > Geert > > *Van:* [email protected] [mailto: > [email protected]] *Namens *Abishek N > *Verzonden:* donderdag 5 mei 2011 20:34 > *Aan:* General MarkLogic Developer Discussion > *Onderwerp:* Re: [MarkLogic Dev General] Try catch in xquery > > > Thanks Geert for your response.. I agree with you on those lines., that's > the default way we handle exception scenarios in other programming > languages. The question around the try catch block is more with respect to > the impact on parallel processing and lazy evaluations which is applicable > for ML .. > On Thu, May 5, 2011 at 1:46 PM, Geert Josten <[email protected]> > wrote: > Hi Abishek, > > What is meant with ‘reduce the use of try/catch’ is that you should make > sensible use of try/catch and manually throwing exceptions using the error > function. Exception handling is (relatively) slow in most languages, so if > you have the option to prevent a throw and a catch by simply using an extra > if, then do so. On other occasions, you might want to be sure certain > statements are always executed, or that certain actions are taken when an > exception is thrown. > > A good example is trying to connect to an external resource using > xdmp:http-get. If it fails with a timeout, it throws an exception. It is not > uncommon to put a try catch around it and connect to a different resource, > or return some default value instead. > > Personally, I don’t bother about try/catch performance too much. Just use > them sensibly.. > > Kind regards, > Geert > > *Van:* [email protected] [mailto: > [email protected]] *Namens *Abishek N > *Verzonden:* donderdag 5 mei 2011 19:05 > *Aan:* General MarkLogic Developer Discussion > *Onderwerp:* [MarkLogic Dev General] Try catch in xquery > > > What are the pointers while exception handling in ml? One of the pointers > we have already heard is > "Reduce the use of try/catch where applicable. This is especially true in > situations where try/catch blocks may be nested. Try/catch blocks have a > negative impact on performance due to the fact that the block must be > completely evaluated before the server can move on. " > > So does this mean that we have to avoid having try catch blocks around > lots of lines of code? and try to keep the try catch block as short as > possible.. > So in the eg. below statement 3 try catch block would not be triggered > until the statement 1 and statement 2 get executed, is that correct? Since > statement 2 is outside try catches there is a possibility it could get lazy > evaluated. > > try { > statement 1 > } > catch{ > } > > statement 2 > > try { > statement 3 > } > catch{ > } > > Similarly in the below scenario.. if we have nested try catches like > below... statement 5 would not get executed until statement 1,2,3 get > executed.. however statement 4 could get executed.. > try { > try > { > statement 1 > } > catch{ > } > > statement 2 > > try { > statement 3 > } > catch{ > } > > } > > statement 4 > > try { > statement 5 > } > catch{ > } > > Please confirm if our understanding is correct. > > Regards Abishek > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > -- > Regards Abishek > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > -- Regards Abishek
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
