Post reply

Try.. Catch..

  • October 8, 2013 at 9:23 pm

    #299027

    Comments posted to this topic are about the item Try.. Catch..

  • October 8, 2013 at 10:36 pm

    #1656983

    very easy one to start your day.

    going back to basics 🙂

  • October 8, 2013 at 10:56 pm

    #1656986

    Mr. Kapsicum (10/8/2013)

    very easy one to start your day.

    going back to basics 🙂

    +1

  • October 9, 2013 at 12:55 am

    #1656999

    Interesting... Thanks.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • October 9, 2013 at 1:57 am

    #1657019

    Super easy.

  • October 9, 2013 at 1:59 am

    #1657020

    Nice and easy question. Thanks. 🙂

  • October 9, 2013 at 2:01 am

    #1657021

    Guessed right, as it would have been a pretty pointless question if the answer had been Yes!

  • October 9, 2013 at 2:59 am

    This was removed by the editor as SPAM

  • October 9, 2013 at 3:12 am

    #1657042

    Nice question.

    I've never understood why try...catch was banned in functions, but the explanation for this question provides a clue. I'd never seen the error messages, and their text is that clue.

    These error messages mentioned in the explanation seem a bit odd. Of course the classical definition of a function is that it has no side effects, and if the intention is to enforce that then excluding things like insert, delete, and update statements against anything other than local table variables is a reasonable (indeed essential) decision, as are various other exclusions; but claiming that "begin try" or "begin catch" is a side-effecting operation seems somewhat strange. Off the top of my head I can see no imaginable way in which these statements can effect the state of any database data or metadata (the statements inside the try or catch block could, but inside a function the try or catch block can't contain any such statement simply because there they would be inside the function body, and are themselves banned quite apart frm the try or catch) so I have to say that it appears to me that the wording chosen for those error messages is misleading claptrap.

    It would be nice to know what the real reason for excluding those statement is, and whether it has any validity or is just silliness, because if it is just silliness we might be able to persuade MS to allow this very useful error detection and containment construct inside multi-statement functions.

    edit:spelling

    Tom

  • October 9, 2013 at 3:24 am

    #1657047

    NO.

  • October 9, 2013 at 3:30 am

    #1657049

    Toreador (10/9/2013)

    Guessed right, as it would have been a pretty pointless question if the answer had been Yes!

    +1 (Same)

    Thanks & Best Regards,
    Hany Helmy
    SQL Server Database Consultant

  • October 9, 2013 at 4:03 am

    #1657056

    +1 .... good knowledge base question

  • October 9, 2013 at 6:17 am

    #1657105

    Good Question. Thanks for the easy point.

    L' Eomot Inversé (10/9/2013)

    Nice question.

    I've never understood why try...catch was banned in functions, but the explanation for this question provides a clue. I'd never seen the error messages, and their text is that clue.

    These error messages mentioned in the explanation seem a bit odd. Of course the classical definition of a function is that it has no side effects, and if the intention is to enforce that then excluding things like insert, delete, and update statements against anything other than local table variables is a reasonable (indeed essential) decision, as are various other exclusions; but claiming that "begin try" or "begin catch" is a side-effecting operation seems somewhat strange. Off the top of my head I can see no imaginable way in which these statements can effect the state of any database data or metadata (the statements inside the try or catch block could, but inside a function the try or catch block can't contain any such statement simply because there they would be inside the function body, and are themselves banned quite apart frm the try or catch) so I have to say that it appears to me that the wording chosen for those error messages is misleading claptrap.

    It would be nice to know what the real reason for excluding those statement is, and whether it has any validity or is just silliness, because if it is just silliness we might be able to persuade MS to allow this very useful error detection and containment construct inside multi-statement functions.

    edit:spelling

    Learned something..

  • October 9, 2013 at 6:38 am

    #1657114

    I only knew the answer because I'd tried it before. Since the ISNUMERIC() function is fundamentally broken, I tried creating a function that would actually try to cast the value to a numeric within a try/catch block and return the result. Of course this would have been horrifyingly inefficient for general use, but in a scenario where one record in 5000 was choking on a type conversion, it would have been useful in tracking it down. Sadly it was not to be.

    ron

    -----
    a haiku...

    NULL is not zero
    NULL is not an empty string
    NULL is the unknown

  • October 9, 2013 at 7:15 am

    #1657129

    +1 on the nice and easy question

Viewing 15 posts - 1 through 15 (of 32 total)

You must be logged in to reply to this topic. Login to reply