Orchid Win7 v1 <voi### [at] devnull> wrote:
> I think exception handling predates OO.

The first object-oriented programming language was Simula, developed
in 1967. When was exception handling first used?

-- 
                                                          - Warp

Post a reply to this message

On Sun, 24 Feb 2013 20:01:56 +0000, Orchid Win7 v1 wrote:

>> The exception handling part is a feature of OO programming languages,
>> IIRC.  Bash scripting is far from OOP. ;)
> 
> I think exception handling predates OO. 

Well, I'm referring to things like catching exceptions.  That's something 
that IIRC came with OOP.

Prior to that, for example, in C, if you opened a file and then tried to 
do something with it if the open() call failed, you'd end up segfaulting 
unless you checked for an exception.

So I guess, in a way, that is "exception handling", but I'm talking about 
things like the Python "try:" method, or hooking failures.  You could 
kinda do it in various languages in various ways, but there wasn't a very 
standardized way to do it.

I may not be explaining it well. :)

> But whatever; Bash is a
> _scripting language_. It is meant for writing short, simple scripts, but
> building large, complex, mission-critical applications.

That I absolutely agree with. :)

Jim

Post a reply to this message

Am 24.02.2013 20:49, schrieb Jim Henderson:
> On Sun, 24 Feb 2013 12:21:51 +0000, Orchid Win7 v1 wrote:
>
>> On 24/02/2013 12:03 PM, Warp wrote:
>>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>>> I agree. However, unfortunately it seems that by default Bash ignores
>>>> all such errors and happily proceeds, unless you manually suffix every
>>>> single command with an explicit return-code check.
>>>
>>> How is that different from any programming language?
>>
>> In C#, Java or similar, if you try to open a file and can't, an
>> exception is thrown, and your program is halted. (Unless you thought of
>> that eventuality and coded a catch{} block for it.) In Bash, the program
>> continues to execute as if everything worked just fine, silently
>> ignoring the error.
>
> The exception handling part is a feature of OO programming languages,
> IIRC.  Bash scripting is far from OOP. ;)

Exception handling is not an OOP feature. And yes, bash /does/ have it:

   set -e
   trap "echo aborted by user || kill -INT $$" INT
   trap "echo aborted by other process || kill -TERM $$" TERM
   trap "echo error reported" EXIT

     ... critical section ...

   set +e
   trap - INT
   trap - TERM
   trap - EXIT

Post a reply to this message

Am 24.02.2013 21:01, schrieb Orchid Win7 v1:
>>> I agree. However, unfortunately it seems that by default Bash ignores
>>> all such errors and happily proceeds, unless you manually suffix every
>>> single command with an explicit return-code check.
>>
>> #!/bin/bash -e
>>
>> Have fun!
>
> I think you mean "set -e", but anyway...

Allegedly the above syntax is supposed to work, too. Provided of course 
that it's the very first line of the script.

Post a reply to this message

>>> #!/bin/bash -e
>>>
>>> Have fun!
>>
>> I think you mean "set -e", but anyway...
>
> Allegedly the above syntax is supposed to work, too. Provided of course
> that it's the very first line of the script.

According to the manpage I read, it's supposed to work anywhere in the 
script, so you can turn the feature on and off at will.

I especially love how set -e turns it ON and set +e turns it OFF. I 
think that's really special...

Post a reply to this message

Funny story, interesting that Linux works that way - I wouldn't have 
known that (but then it took me almost a week to get my bitTorrent 
client write access to an external hard drive under Linux).

> Fortunately, the fix is very simple. You just need to add a check for
> the possibility of there being zero devices.

I guess you can use this as a lesson to try and dream up some more 
possible failure modes (eg something else uses up disk space whilst you 
are installing, or ...). It only takes a half hour session and you might 
be surprised what other things you can't handle.

Also it would seem to me to make sense to have a "catch all" type check 
at the end of the installation (eg count folders/files or file sizes or 
md5 on the supposedly installed folder) to really be 100% sure the 
installation worked. At least then if it fails for some crazy reason 
you'll catch it.

> Also, somebody give that tester a medal. There's no way in hell we would
> have thought to actually *test* for such an obscure condition.

You shouldn't give him a medal then... just saying.

Post a reply to this message

> On 23/02/2013 10:24 PM, Francois Labreque wrote:
>
>> 1. Redirect stderr to a different file. And check for that file being
>> more than 0 bytes before claiming the install completed succesfully.
>
> Ooo, here's an interesting question - what is the size of /dev/sda? Is
> it the size of the special file, or the device to which it refers?

It's the size of the special file.  If you want to know the size on the 
device, you'll have to parse the output of df.

But that's not what I meant.  You redirect stderr to a file and then you 
check that THAT file's size is not zero with [ -s $ErrorLog ]

Come to think of it, you should also test that /dev/sba is a block 
device before trying to dd to it using [ -b /dev/sda ]



-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Sun, 24 Feb 2013 23:38:16 +0100, clipka wrote:

> Am 24.02.2013 20:49, schrieb Jim Henderson:
>> On Sun, 24 Feb 2013 12:21:51 +0000, Orchid Win7 v1 wrote:
>>
>>> On 24/02/2013 12:03 PM, Warp wrote:
>>>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>>>> I agree. However, unfortunately it seems that by default Bash
>>>>> ignores all such errors and happily proceeds, unless you manually
>>>>> suffix every single command with an explicit return-code check.
>>>>
>>>> How is that different from any programming language?
>>>
>>> In C#, Java or similar, if you try to open a file and can't, an
>>> exception is thrown, and your program is halted. (Unless you thought
>>> of that eventuality and coded a catch{} block for it.) In Bash, the
>>> program continues to execute as if everything worked just fine,
>>> silently ignoring the error.
>>
>> The exception handling part is a feature of OO programming languages,
>> IIRC.  Bash scripting is far from OOP. ;)
> 
> Exception handling is not an OOP feature. And yes, bash /does/ have it:
> 
>    set -e trap "echo aborted by user || kill -INT $$" INT trap "echo
>    aborted by other process || kill -TERM $$" TERM trap "echo error
>    reported" EXIT
> 
>      ... critical section ...
> 
>    set +e trap - INT trap - TERM trap - EXIT

Interesting, I didn't know that.  Thanks!

Jim

Post a reply to this message

>> Ooo, here's an interesting question - what is the size of /dev/sda? Is
>> it the size of the special file, or the device to which it refers?
>
> It's the size of the special file.

Figures.

> If you want to know the size on the
> device, you'll have to parse the output of df.

Only if the device is *mounted*. ;-)

I believe we used sdisk to do the job.

> Come to think of it, you should also test that /dev/sba is a block
> device before trying to dd to it using [ -b /dev/sda ]

Yes, that was the solution I chose in the end. It's an easy fix.

Post a reply to this message

>> Exception handling is not an OOP feature. And yes, bash /does/ have it:
>>
>>     set -e trap "echo aborted by user || kill -INT $$" INT trap "echo
>>     aborted by other process || kill -TERM $$" TERM trap "echo error
>>     reported" EXIT
>>
>>       ... critical section ...
>>
>>     set +e trap - INT trap - TERM trap - EXIT
>
> Interesting, I didn't know that.  Thanks!

It's truly terrifying just how much stuff you /can/ do with Bash.

(At this point I must remind you that just because you /can/ does NOT, 
in any way, imply that you /should/!!)

Post a reply to this message