Jump to page: 1 2
Thread overview
[phobos] isemail error handling
Mar 04, 2011
Jacob Carlborg
Mar 04, 2011
Jonathan M Davis
Mar 04, 2011
Jesse Phillips
Mar 04, 2011
Jonathan M Davis
Mar 05, 2011
Jacob Carlborg
Mar 05, 2011
Jacob Carlborg
Mar 05, 2011
Jonathan M Davis
Mar 04, 2011
Walter Bright
Mar 05, 2011
Jacob Carlborg
Mar 05, 2011
Walter Bright
March 04, 2011
I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.

If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.

The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?

-- 
/Jacob Carlborg

March 04, 2011
On Friday, March 04, 2011 14:12:01 Jacob Carlborg wrote:
> I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.
> 
> If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.
> 
> The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?

What kind of errors does it need to handle? If all it's doing is verifying whether a string is a valid e-mail address, how can you get errors from that? Either it's valid or it isn't. I have no idea what it could possibly be erroring out on.

- Jonathan M Davis
March 04, 2011
Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).

On Fri, Mar 4, 2011 at 2:12 PM, Jacob Carlborg <doob at me.com> wrote:
> I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.
>
> If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.
>
> The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw
March 04, 2011
On Friday, March 04, 2011 15:25:05 Jesse Phillips wrote:
> Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).

Those aren't exceptions then. An exception would be for an error of some kind in running your function. But there is no error in running your function. It's validly running and telling you that the input was not a valid e-mail address. There's no error there. So, it looks like it either needs an additional out parameter or to return a tuple with whether the address is valid and the reason.

Since there are likely a lot of cases that the programmer doesn't care why the e-mail address is invalid, you should probably create two versions of the function (probably one which wraps the other), where one has an out parameter for the reason that the address is invalid and the other doesn't.

- Jonathan M Davis
March 04, 2011
I agree, it is not an "error", and so should not be an exception.

Jesse Phillips wrote:
> Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).
>
> On Fri, Mar 4, 2011 at 2:12 PM, Jacob Carlborg <doob at me.com> wrote:
> 
>> I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.
>>
>> If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.
>>
>> The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?
>>
>>
>> 
> 
March 04, 2011
It's a sort of a status code. Different applications are fine with different status codes.

Andrei

On 3/4/11 5:47 PM, Walter Bright wrote:
> I agree, it is not an "error", and so should not be an exception.
>
> Jesse Phillips wrote:
>> Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).
>>
>> On Fri, Mar 4, 2011 at 2:12 PM, Jacob Carlborg <doob at me.com> wrote:
>>> I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.
>>>
>>> If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.
>>>
>>> The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?
>>>
>>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
March 05, 2011
Yeah, I guess it's more of a "reason code" than error code. But it feels like going back to C, returning status codes and have to look them up in some kind of table.

-- 
/Jacob Carlborg

On 5 mar 2011, at 00:25, Jesse Phillips wrote:

> Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).
> 
> On Fri, Mar 4, 2011 at 2:12 PM, Jacob Carlborg <doob at me.com> wrote:
>> I've ported the isemail module from PHP to D and I'm now working on adding exceptions instead of error codes. The PHP function takes an error level parameter indicating what kind of error level you want. You can pass in a warning and error level and possible others as well. You can also turn the error handling completely off. If the error handling is turned off the function will only return "true" or "false" indicating if the email address is valid or not.
>> 
>> If the error handling is on the function will return 0 if the email address is valid or otherwise an error code indicating what the error was.
>> 
>> The question I now has is: should we keep these different error levels or should we just have a parameter indicating if the error handling is on or off?
>> 
>> --
>> /Jacob Carlborg
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> 
> 
> 
> -- 
> Liberty means responsibility. That is why most men dread it.
>   - George Bernard Shaw
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

March 05, 2011
The PHP version returns "true", "false" or a code indicating why the email address isn't valid. In addition to that it has an out parameter, an array, containing among other things the local and the domain part of the address. I was thinking that I either keep it like that, with an out parameter, or return a struct with the information.

If I return a struct I was thinking it would contain the following fields:

bool valid;
string local;
string domain;
int statusCode/reasonCode;

And also make the struct implicitly convertible to bool. Would that be too much to return by value?

-- 
/Jacob Carlborg

On 5 mar 2011, at 00:46, Jonathan M Davis wrote:

> On Friday, March 04, 2011 15:25:05 Jesse Phillips wrote:
>> Is there a reason to make them exceptions? The whole point is to tell you if it is or is not a function. I would not consider it an error code more a "reason code" (why it wasn't an email address).
> 
> Those aren't exceptions then. An exception would be for an error of some kind in running your function. But there is no error in running your function. It's validly running and telling you that the input was not a valid e-mail address. There's no error there. So, it looks like it either needs an additional out parameter or to return a tuple with whether the address is valid and the reason.
> 
> Since there are likely a lot of cases that the programmer doesn't care why the e-mail address is invalid, you should probably create two versions of the function (probably one which wraps the other), where one has an out parameter for the reason that the address is invalid and the other doesn't.
> 
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

March 05, 2011
Make the status code an enum.

Andrei

On 3/5/11 5:07 AM, Jacob Carlborg wrote:
> The PHP version returns "true", "false" or a code indicating why the email address isn't valid. In addition to that it has an out parameter, an array, containing among other things the local and the domain part of the address. I was thinking that I either keep it like that, with an out parameter, or return a struct with the information.
>
> If I return a struct I was thinking it would contain the following fields:
>
> bool valid;
> string local;
> string domain;
> int statusCode/reasonCode;
>
> And also make the struct implicitly convertible to bool. Would that be too much to return by value?
>
March 05, 2011
Yes of course, it's already an enum. I was concerned about the size of the struct or is it small enough to return by value?

-- 
/Jacob Carlborg

On 5 mar 2011, at 14:44, Andrei Alexandrescu wrote:

> Make the status code an enum.
> 
> Andrei
> 
> On 3/5/11 5:07 AM, Jacob Carlborg wrote:
>> The PHP version returns "true", "false" or a code indicating why the email address isn't valid. In addition to that it has an out parameter, an array, containing among other things the local and the domain part of the address. I was thinking that I either keep it like that, with an out parameter, or return a struct with the information.
>> 
>> If I return a struct I was thinking it would contain the following fields:
>> 
>> bool valid;
>> string local;
>> string domain;
>> int statusCode/reasonCode;
>> 
>> And also make the struct implicitly convertible to bool. Would that be too much to return by value?
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

« First   ‹ Prev
1 2