Re: capture exception

At the risk of oversimplifying the issue:
BAD: eval "MY CODE";
GOOD: eval {MY CODE};

On Tue, May 30, 2017 at 12:00 PM, Hiram Gibbard <[email protected]> wrote:

> I might be hijacking this... Sorry, but...I recently used the Perl eval
> function to determine if a ldap search returned a error or not. Basically,
> a user's record has a attribute that points to a assistant, and If that
> assistant no longer exists the app was throwing a error since it executed a
> ldap call to that assistant's record. So I used eval to check if the error
> was returned, and if so, skipped the function where it tied searched the
> assistant record in ldap.  Is this the same eval scenario you described
> which has a security whole?
>
>
> I was just reading everyone's reply and now I am worried I created a
> security hole.
>
> Thanks
>
> On Tue, May 30, 2017 at 10:04 AM, Dirk-Willem van Gulik <
> [email protected]> wrote:
>
>>
>> > On 30 May 2017, at 16:58, [email protected] wrote:
>> >
>> > On Tuesday 30 May 2017 15:53:13 James Smith wrote:
>> >> String eval should be avoided at all costs [especially if you parse
>> user
>> >> input] - functional eval is different - and is a good model for
>> catching
>> >> errors etc
>> >
>> > Yes, string eval should be avoided in all usage. But this discussion was
>> > about that functional eval.
>>
>> Aye - right you are - apologies for causing confusing and missing the (/{.
>>
>> Dw.
>>
>
>
>
> --
> Hiram Gibbard
> [email protected]
> http://hiramgibbard.com
>
>


-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*[email protected] <[email protected]>*

*Customer Service:*
877.268.6667
[email protected]