Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-09-06 17:29:42

On Sep 6, 2009, at 5:09 PM, Pierre Morcello wrote:

>>>>> What is a "break-scope problem" to you? I think you might use  
>>>>> the wrong "analysis pattern" here...
>
> I was reusing the same kind of words than the previous comment of  
> Stefan Strasser, to answer clearly to his remarks. Sorry if it made  
> things less clear: He wrote
> "if you need a construct that forms a scope, accomplishes a tasks  
> and then
> exists the scope from anywhere in between, that's a function.". He  
> was presenting things like a problem and its solution.
>
> I have never heard of 'analysis pattern', only 'design patterns' and  
> 'idioms'. I will look at this.
>
> Anyway just let compare 2 sample codes:
>
> Of course people can already write :
> if(!filestream.bad())
> {
>    if(!filestream.good())
>   {
>     if(xmlLoadFrom(filestream))
>    {
>        // and so on, to test if the xml is valid, etc...
>    }else{
>       log("the file is no xml document.");
>     }
>   }else{
>     log("error inside the file (eof)");
>    }
> }else{
>   log("error at opening file");
> }
>
> and :
>
> Breakable
> {
>   if(!filestream.bad())
>   {
>       log("error at opening file");
>       break;
>   }
>
>   if(!filestream.good())
>   {
>      log("error inside the file (eof)");
>      break;
>   }
>
>   if(!xmlLoadFrom(filestream))
>   {
>      log("the file is no xml document.");
>      break;
>   }
>
>   // and so on, to test if the xml is valid, etc...
> }
>
> Have a deep breath, compare, and then tell me which is more readable.
> Which is the easier to maintain?
> If another test is to be added, which version will be the simpliest  
> to modify?
>
> For these 3 reasons, I prefer the second one.
>
> If you think this usage might lead to problems, could you explain  
> which ones ?

This is the typical use, that of exceptional cases. Luckily, what is  
exceptional at one level can be totally tolerable at a higher (and  
invoking and/or embedding...) level, thus we can use a try-catch  
construct and throw an exception.

I am not a friend of emulating local exception handling by breaks. So,  
in this case (and even meta case) I would use

try {
   if (filestream.bad())
     throw boost::exception("error at opening file");
   if (!filestream.good())
     throw boost::exception("error inside the file (eof)");

   // Main logic

   xmlLoadFrom(filestream); // assuming that 'xmlLoadFrom' uses  
exceptions properly as well...	
}
catch (const boost::exception& ex) {
   log(ex.what());
}

> Best regards,
>
> Pierre
>
> PS: if you know a good source about "analysis pattern", don't  
> hesitate to tell me. Right now, I will check the wikipedia page.

I just coined that term - at least AFAIK. What I meant by it? Well,  
similar to design pattern but applied in the analysis of problems, as  
a Minsky frame, perhaps.

/David