Try.. Catch..

  • Pulivarthi Sasidhar

    SSCertifiable

    Points: 6706

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

  • Mr. Kapsicum

    SSCertifiable

    Points: 6128

    very easy one to start your day.

    going back to basics ๐Ÿ™‚

  • PRAMANA.DBA

    SSCertifiable

    Points: 5507

    Mr. Kapsicum (10/8/2013)


    very easy one to start your day.

    going back to basics ๐Ÿ™‚

    +1

  • Koen Verbeeck

    SSC Guru

    Points: 258955

    Interesting... Thanks.

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

  • ksatpute123

    Hall of Fame

    Points: 3325

    Super easy.

  • sqlnaive

    SSCoach

    Points: 17435

    Nice and easy question. Thanks. ๐Ÿ™‚

  • Toreador

    SSChampion

    Points: 11242

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

  • This was removed by the editor as SPAM

  • TomThomson

    SSC Guru

    Points: 104772

    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

  • T.Ashish

    SSCarpal Tunnel

    Points: 4244

    NO.

  • Hany Helmy

    SSChampion

    Points: 13435

    Toreador (10/9/2013)


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

    +1 (Same)

  • twin.devil

    SSC-Insane

    Points: 22208

    +1 .... good knowledge base question

  • Jamsheer

    Ten Centuries

    Points: 1136

    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..

  • ronmoses@gmail.com

    SSCarpal Tunnel

    Points: 4480

    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

  • logitestus

    SSCrazy

    Points: 2817

    +1 on the nice and easy question

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

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