At 11:25 AM 8/4/00 +0200, Johan Vromans wrote:
>[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> > Yes, but... this is largely casued by the fact that Java requires you to
> > declare any uncaught parameters on your method specification, and this
> > tends to have a na
On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error c
>> Why would we ever remove a syscall!?!?
>I vote for migration to a module.
And sysopen and fcntl and waitpid and ioctl
Tom Christiansen writes:
> >Maybe we should address this? If we're keeping syscalls just because a
> >possible replacement module is just written wrong, we should fix this.
>
> Why would we ever remove a syscall!?!?
I vote for migration to a module. If you're going to use the
long-winded form o
>Tom Christiansen wrote:
>>
>> >> Thats just because IO::Socket is done wrong
>>
>> >Maybe we should address this? If we're keeping syscalls just because a
>> >possible replacement module is just written wrong, we should fix this.
>>
>> Why would we ever remove a syscall!?!?
>Sorry, wrong verb
Tom Christiansen wrote:
>
> >> Thats just because IO::Socket is done wrong
>
> >Maybe we should address this? If we're keeping syscalls just because a
> >possible replacement module is just written wrong, we should fix this.
>
> Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I me
>> Thats just because IO::Socket is done wrong
>Maybe we should address this? If we're keeping syscalls just because a
>possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
--tom
> Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift || 2345
On Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote:
> This is my argument against obsolescing the general-purpose socket() et al.
> syscalls in deference to the IO::Socket stuff:
Absolutly. A high level API is ok for those who want it. But you should
never take away the low-level s
>> If you do it the C++ way, you can say:
>> try {
>> first_sub_that_throws_exceptions();
>> second_sub_that_throws_exceptions();
>> } catch {
>> it went wrong
>> }
>How does 'it went wrong' know _which_ of the subs went wrong?
This is my argument against obsolescing
On Fri, Aug 04, 2000 at 11:25:49AM +0200, Johan Vromans wrote:
> How does 'it went wrong' know _which_ of the subs went wrong? For
> example:
>
> try {
> open(file1);
> open(file2);
> open(file3);
> } catch {
> error("could not open one of the file(s)");
> }
>
> which is no
[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> Yes, but... this is largely casued by the fact that Java requires you to
> declare any uncaught parameters on your method specification, and this
> tends to have a nasty oil-slick effect.
>
> If you do it the C++ way, y
Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen (and it _does_ happen in almost every Java
> program I've seen):
>
> try {
>open file
>while read a record
> process its
Steve Simmons <[EMAIL PROTECTED]> writes:
> On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> >try {
> > java
> >}
> >catch (Exception e) {
> > think again
> >}
>
> I like this. It's perlish in that it builds off of a well-defined and
> proven mechanis
14 matches
Mail list logo
