On 05/12/2017 10:32 AM, k-five wrote:
> Interesting! I was worried about performance and for that I did not want
> to use try-catch.
> So (isNumberic) is a good solution.
> http://dlang.org/phobos/std_traits.html#isNumeric

If you're doing this for speed, you better be benchmarking. Exceptions are slow when they're thrown. But if no exception is being thrown, try-catch is probably faster than checking isNumeric beforehand.

On Fri, May 12, 2017 at 12:47:04PM +0200, ag0aep6g via Digitalmars-d-learn wrote:
> On 05/12/2017 10:32 AM, k-five wrote:
> > Interesting! I was worried about performance and for that I did not
> > want to use try-catch.
> > So (isNumberic) is a good solution.
> > http://dlang.org/phobos/std_traits.html#isNumeric
> 
> If you're doing this for speed, you better be benchmarking. Exceptions are slow when they're thrown. But if no exception is being thrown, try-catch is probably faster than checking isNumeric beforehand.

Yes, when it comes to performance-related issues, always profile, profile, profile. (Or benchmark, benchmark, benchmark. Anything that gives you actual measurements rather than subjective judgment calls.) Far too often, what we think will perform poorly is actually nowhere near the real bottleneck in the program, and we end up wasting too much time "optimizing" something that doesn't even make a noticeable difference in the end. Whereas, using a profiler early on will help you zero in on the real bottlenecks, and you could potentially make huge performance savings with much less effort.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

On Thursday, 11 May 2017 at 16:07:22 UTC, k-five wrote:
> On Wednesday, 10 May 2017 at 21:19:21 UTC, Stanislav Blinov wrote:
>> On Wednesday, 10 May 2017 at 15:35:24 UTC, k-five wrote:
>>> On Wednesday, 10 May 2017 at 14:27:46 UTC, Stanislav Blinov
> ---------------------------------------------------------------
>> I don't understand. If you don't want to take care of exceptions, then you just don't do anything, simply call to!int(str).
>
> Well I did that, but when the string is a valid type like: "10" there is no problems. But when the string is not valid, like: "abc", then to! function throws an exception.
>
> Why I do not want to take care of that? Because I just need the value, if the string is valid, otherwise no matter what the value of string is.
>
> First I just wrote:
> index = to!int( user_apply[ 4 ] );
>
> And this code is a part of a command-line program and the user may enter anything. So, for a valid string:
> ./program '10'   // okey
>
> but for:
> ./program 'non-numerical' // throws an exception an 10 lines of error appear on the screen( console )
>
> I just want to silent this exception. Of course it is useful for handling when someone wants to. But in my code I no need to handle it. So I want to silent that, without using try{}catch(){} block. I just wondered about try-catch and I want to know may there would be a better way instead of a dummy try-catch block.
>
> Thanks for replying and mentioning. And I am sorry, since I an new in English Writing, if you got confuse.

You are not making a lot of sense:

1. Exception do bubble up, so you don't need to "handle" exceptions at the call site if you don't want to. The whole point of exceptions is do effectively do what you want.

2. You say that you don't have to deal with it in your code but you are trying to deal with it now.


You are not clear on exactly what you are trying to accomplish.

Can you be more specific on why you do not want to add a try/catch/if-else/ifThrown/etc? Is it because you don't need to handle it in your own usage? If that is true, will others ever use it?

Basically all you have to do is ask yourself this:

"Do I need to EVER handle the case where the data is invalid?"

If you do(e.g., other users will use your code) then you better implement some type of exception handling. Else all you have to do is always put in the right data(not good because it might bite you in the ass one day).

If you just want less noise when the program crashes, just put a try/catch block in main and catch all generic exceptions and exit with a simple error message like "There was an ERROR, I do not know why...".

On Saturday, 13 May 2017 at 02:40:17 UTC, Mike B Johnson wrote:
>
> You are not making a lot of sense:
>
> 1. Exception do bubble up, so you don't need to "handle" exceptions at the call site if you don't want to. The whole point of exceptions is do effectively do what you want.
>
> 2. You say that you don't have to deal with it in your code but you are trying to deal with it now.
>
>
> You are not clear on exactly what you are trying to accomplish.
>
> Can you be more specific on why you do not want to add a try/catch/if-else/ifThrown/etc? Is it because you don't need to handle it in your own usage? If that is true, will others ever use it?
>
> Basically all you have to do is ask yourself this:
>
> "Do I need to EVER handle the case where the data is invalid?"
>
> If you do(e.g., other users will use your code) then you better implement some type of exception handling. Else all you have to do is always put in the right data(not good because it might bite you in the ass one day).
>
> If you just want less noise when the program crashes, just put a try/catch block in main and catch all generic exceptions and exit with a simple error message like "There was an ERROR, I do not know why...".

----------------------------------------------------------------

Way arguing when a simple code can clarify the subject? right?
If am not clear so consider me as an stupid man, no problem at all.

but CAN you please solve it for me?

import std.stdio:	writeln;
import std.conv:	to;

void main( string[] args ){
	
	string str = "10";
	int index;
	index = to!int( str );	// okay, no exception are thrown
	
	str = "some-words";
	index = to!int( str ); // problem, an exception is thrown
	
}

Please run this code and convert "some-words" to int by using to! function without facing any exception. Thanks

On Friday, May 12, 2017 10:42:18 H. S. Teoh via Digitalmars-d-learn wrote:
> On Fri, May 12, 2017 at 12:47:04PM +0200, ag0aep6g via Digitalmars-d-learn
wrote:
> > On 05/12/2017 10:32 AM, k-five wrote:
> > > Interesting! I was worried about performance and for that I did not
> > > want to use try-catch.
> > > So (isNumberic) is a good solution.
> > > http://dlang.org/phobos/std_traits.html#isNumeric
> >
> > If you're doing this for speed, you better be benchmarking. Exceptions are slow when they're thrown. But if no exception is being thrown, try-catch is probably faster than checking isNumeric beforehand.
>
> Yes, when it comes to performance-related issues, always profile, profile, profile. (Or benchmark, benchmark, benchmark. Anything that gives you actual measurements rather than subjective judgment calls.) Far too often, what we think will perform poorly is actually nowhere near the real bottleneck in the program, and we end up wasting too much time "optimizing" something that doesn't even make a noticeable difference in the end. Whereas, using a profiler early on will help you zero in on the real bottlenecks, and you could potentially make huge performance savings with much less effort.

For the most part, when parsing a string, std.conv.to's approach of just parsing the string and throwing an exception if/when it fails is the most efficient, because it's only going to parse the string once, whereas calling a function to validate the string's format and _then_ do the conversion would mean parsing the string twice. It's just that if you are in a situation where the string is likely not to be in the correct format, then having a bunch of exceptions thrown will harm performance. To best handle that, we'd need an alternate conversion function that did something like return the failure condition and passed the result via an out parameter or one which took a default value and returned that on failure instead of what was actaully parsed. So, ideally, we'd have other functions in std.conv to handle such cases, but in the vast majority of cases, throwing an exception on failure is going to be the most efficient solution.

But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it - especially if you're throwing exceptions on a regular basis but not super frequently, because then it's quickly an open question as to whether parsing twice to avoid the exception or letting the exception be thrown and caught would be faster.

Odds are though that unless you're converting in a tight loop, the relative costs won't matter much, even if one is clearly more expensive than the other, simply because it's not a bottleneck in your program. But you won't know that for sure unless you profile.

However, unless you're parsing a lot of invalid strings, I'd be very surprised if always parsing twice were more efficient than parsing only once and throwing an exception on failure. And D exceptions are fairly efficient at this point if you don't call toString, because we stripped out most of the string processing that they were doing up front before. It used to be pretty painful when you did a lot of tests that tested the error cases, because the exceptions really increased the time that the tests took, but that's no longer the case (IIRC, the improvements literally saved seconds of execution time in std.datetime's unit tests).

- Jonathan M Davis

On Saturday, 13 May 2017 at 08:50:20 UTC, k-five wrote:

> Way arguing when a simple code can clarify the subject? right?
> If am not clear so consider me as an stupid man, no problem at all.
>
> but CAN you please solve it for me?
>
> import std.stdio:	writeln;
> import std.conv:	to;
>
> void main( string[] args ){
> 	
> 	string str = "10";
> 	int index;
> 	index = to!int( str );	// okay, no exception are thrown
> 	
> 	str = "some-words";
> 	index = to!int( str ); // problem, an exception is thrown
> 	
> }
>
> Please run this code and convert "some-words" to int by using to! function without facing any exception. Thanks

Please don't take it the wrong way. It just seems that Mike was as confused by your questions as I was initially. But it's clear that's just the language barrier, nothing more. See, you said:

> Why I do not want to take care of that? Because I just need the value, if the string is valid, otherwise no matter what the value of string is.

...but it doesn't make sense to have an int "value" for a string like "some-words". *Unless* one defines a "not-a-number" equivalent for an int, i.e. 0 or some other value. That part was hard to infer from what you were saying :) It might've been obvious for you, but hard to understand from what you wrote.

This was what made things clear:

> I just want to silent this exception...

Mostly, the source of the confusion was the "I don't want to handle the exception". But in fact what you were asking was was there a way to somehow ignore the exception and just return some predefined value in case of an error. So in fact, you did want to handle the exception (or rather, an exceptional case), you just wanted to do it without inserting control flow instructions (try/catch) into your code. I think the latter part already got covered in others' replies.

Nobody was trying to insult you. With this being a multi-lingual and multi-cultural community, remember that understanding goes both ways, and we're sometimes caught right in the middle, in the clash of mentalities.

On Saturday, 13 May 2017 at 09:05:17 UTC, Jonathan M Davis wrote:

> For the most part, when parsing a string, std.conv.to's approach of just parsing the string and throwing an exception if/when it fails is the most efficient, because it's only going to parse the string once, whereas calling a function to validate the string's format and _then_ do the conversion would mean parsing the string twice.It's just that if you are in a situation where the string is likely not to be in the correct format, then having a bunch of exceptions thrown will harm performance. To best handle that, we'd need an alternate conversion function that did something like return the failure condition and passed the result via an out parameter or one which took a default value and returned that on failure instead of what was actaully parsed. So, ideally, we'd have other functions in std.conv to handle such cases, but in the vast majority of cases, throwing an exception on failure is going to be the most efficient solution.

I did not know this.

> But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it -

Can you please give a link or page or something to read about profile or benchmark. I have no experience with those.

-------------------------------------------------------------------

For a such purpose I already used std::stringstream in C++, and I assumed may or may not D has a such family. ( to!, parse!, ... )

Not only an invalid string like "word" for to!int, makes it being thrown, but an empty string like: "" also makes it.

string str = "word";
int index = to!int( str ); // throws

str = "";
int index = to!int( str ); // throws, as well!

Of course throwing is useful some times, but definitely not ALWAYS, and it is better to have a convert function that never throws anything.

Although [Andrei Alexandrescu] told me that the parse! family is used for such a case:
> Use the "parse" family: https://dlang.org/phobos/std_conv.html#parse -- Andrei
but it throws as well.

On Saturday, 13 May 2017 at 09:51:40 UTC, k-five wrote:
> On Saturday, 13 May 2017 at 09:05:17 UTC, Jonathan M Davis
>> But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it -
>
> Can you please give a link or page or something to read about profile or benchmark. I have no experience with those.

Profiling:
Halfway down this page: http://www.digitalmars.com/ctg/trace.html

Two programs for visualising bottlenecks:
https://bitbucket.org/andrewtrotman/d-profile-viewer
https://code.dlang.org/packages/profdump

Benchmarking:
https://youtu.be/QELK73JSpFk?list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB (fresh from DConf)
https://dlang.org/library/std/datetime/benchmark.html
https://code.dlang.org/packages/std_benchmark
https://code.dlang.org/packages/benchmarkplotter