well, i followed your advice,
i've put a selective exception handler,
look at the following code:
         char[] data;
         try{
     data=cast(char[])std.file.read(d(filename));
            }
         catch(Base64Exception ex) {
              say(d(badfile));
              say("\n" ~ d(goodbye));
              std.c.stdio.getch();
              return 0;
              }
         finally{};

d() is an alias for base64.decode()
say is an alias for writef()

i declared data outside of the try-catch block because otherwise i couldn't
have use the .length property of the array,
anyway..
it does compile, but when i run it an use a test file that contain the
illegal base64 char "!"
i get this:
           Error: Invalid base64 character '!'

so why doesn't the exception is being catched ?
i tried just as well with Base64CharException, gives the same result.

- Asaf

Hi,

On Tue, 26 Oct 2004 21:47:07 +0200, Asaf Karagila <kas1@netvision.net.il> wrote:
> well, i followed your advice,
> i've put a selective exception handler,
> look at the following code:
>          char[] data;
>          try{
>      data=cast(char[])std.file.read(d(filename));
>             }
>          catch(Base64Exception ex) {
>               say(d(badfile));                               say("\n" ~ d(goodbye));
>               std.c.stdio.getch();
>               return 0;
>               }
>          finally{};
>
> d() is an alias for base64.decode()
> say is an alias for writef()
>
> i declared data outside of the try-catch block because otherwise i couldn't
> have use the .length property of the array,
> anyway..
> it does compile, but when i run it an use a test file that contain the
> illegal base64 char "!"
> i get this:
>            Error: Invalid base64 character '!'
>
> so why doesn't the exception is being catched ?
> i tried just as well with Base64CharException, gives the same result.

The exception you want is 'Base64CharException' if you look in std.base64 you'll find it being thrown.

The problem with the code above is this line:
  say(d(badfile));

it is also giving the exception, so while your code catches the exception thrown by
  data=cast(char[])std.file.read(d(filename));

it then generates another exception on
  say(d(badfile));

and prints it's own error.

You can verify this by inserting 'say' calls eg.

import std.base64;
import std.stdio;
import std.file;

alias std.base64.decode d;
alias std.stdio.writef say;

int main(char[][] args)
{
	char[] filename = "one!.txt";
	char[] badfile = "two!.txt";
	char[] goodbye = "bye!";
	char[] data;
	try{
		say("a\n");
		data = cast(char[])std.file.read(d(filename));
		say("b\n");
	}
	catch(Base64CharException e) {
		say("c\n");
		say(d(badfile));
		say("d\n");
		say("\n" ~ d(goodbye));
		std.c.stdio.getch();
		return 0;
	}
	finally{};
}

Which outputs:

a
c
Error: Invalid base64 character '!'

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

i forgot to mention that, my bad.
filename, badfile, goodbye, alld the strings are already encoded in base64,
so its not really the problem of the decoding,
i was sticking the try-catch at the wrong location, i should've stuck it
when it decoded the data.
and now when i did, it worked great.
thanks a lot for all the help !

- Asaf.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsghu7jwe5a2sq9@digitalmars.com...
> Hi,
>
> On Tue, 26 Oct 2004 21:47:07 +0200, Asaf Karagila <kas1@netvision.net.il> wrote:
>> well, i followed your advice,
>> i've put a selective exception handler,
>> look at the following code:
>>          char[] data;
>>          try{
>>      data=cast(char[])std.file.read(d(filename));
>>             }
>>          catch(Base64Exception ex) {
>>               say(d(badfile));                               say("\n" ~
>> d(goodbye));
>>               std.c.stdio.getch();
>>               return 0;
>>               }
>>          finally{};
>>
>> d() is an alias for base64.decode()
>> say is an alias for writef()
>>
>> i declared data outside of the try-catch block because otherwise i
>> couldn't
>> have use the .length property of the array,
>> anyway..
>> it does compile, but when i run it an use a test file that contain the
>> illegal base64 char "!"
>> i get this:
>>            Error: Invalid base64 character '!'
>>
>> so why doesn't the exception is being catched ?
>> i tried just as well with Base64CharException, gives the same result.
>
> The exception you want is 'Base64CharException' if you look in std.base64 you'll find it being thrown.
>
> The problem with the code above is this line:
>   say(d(badfile));
>
> it is also giving the exception, so while your code catches the exception
> thrown by
>   data=cast(char[])std.file.read(d(filename));
>
> it then generates another exception on
>   say(d(badfile));
>
> and prints it's own error.
>
> You can verify this by inserting 'say' calls eg.
>
> import std.base64;
> import std.stdio;
> import std.file;
>
> alias std.base64.decode d;
> alias std.stdio.writef say;
>
> int main(char[][] args)
> {
> char[] filename = "one!.txt";
> char[] badfile = "two!.txt";
> char[] goodbye = "bye!";
> char[] data;
> try{
> say("a\n");
> data = cast(char[])std.file.read(d(filename));
> say("b\n");
> }
> catch(Base64CharException e) {
> say("c\n");
> say(d(badfile));
> say("d\n");
> say("\n" ~ d(goodbye));
> std.c.stdio.getch();
> return 0;
> }
> finally{};
> }
>
> Which outputs:
>
> a
> c
> Error: Invalid base64 character '!'
>
> Regan
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

What about putting a try-catch block in main ?


In article <cl3o0e$j6i$1@digitaldaemon.com>, Asaf Karagila says...
>
>is there a way to install a global exception handler,
>that will handle any unexpected error that occurs, that has no specific
>handler in the code..
>like, a default exception handler..
>
>- Asaf
>
>

ok, and what exactly is it suppose to cacth,
and how would it identify between one exception to another ?

- Asaf

"Sai" <Sai_member@pathlink.com> wrote in message news:clptdo$15oh$1@digitaldaemon.com...
> What about putting a try-catch block in main ?
>
>
> In article <cl3o0e$j6i$1@digitaldaemon.com>, Asaf Karagila says...
>>
>>is there a way to install a global exception handler,
>>that will handle any unexpected error that occurs, that has no specific
>>handler in the code..
>>like, a default exception handler..
>>
>>- Asaf
>>
>>
>
> 

On Thu, 28 Oct 2004 17:43:58 +0200, Asaf Karagila <kas1@netvision.net.il> wrote:
> ok, and what exactly is it suppose to cacth,

Object will catch everything.

> and how would it identify between one exception to another ?

Using cast. Cast returns null if you try to cast to the wrong thing, so you can use a series of casts to determine the exception.

Regan

> - Asaf
>
> "Sai" <Sai_member@pathlink.com> wrote in message
> news:clptdo$15oh$1@digitaldaemon.com...
>> What about putting a try-catch block in main ?
>>
>>
>> In article <cl3o0e$j6i$1@digitaldaemon.com>, Asaf Karagila says...
>>>
>>> is there a way to install a global exception handler,
>>> that will handle any unexpected error that occurs, that has no specific
>>> handler in the code..
>>> like, a default exception handler..
>>>
>>> - Asaf
>>>
>>>
>>
>>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

yeah, i understood that earlier from your posts,
but what if its an unexpected exception ?
the only way i can think of now is to install the handler using
the winapi SetUnhandledExceptionFilter, but i sorta hoped there would be
something like that built-in the language..

- Asaf.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsglknzq75a2sq9@digitalmars.com...
> On Thu, 28 Oct 2004 17:43:58 +0200, Asaf Karagila <kas1@netvision.net.il> wrote:
>> ok, and what exactly is it suppose to cacth,
>
> Object will catch everything.
>
>> and how would it identify between one exception to another ?
>
> Using cast. Cast returns null if you try to cast to the wrong thing, so you can use a series of casts to determine the exception.
>
> Regan
>
>> - Asaf
>>
>> "Sai" <Sai_member@pathlink.com> wrote in message news:clptdo$15oh$1@digitaldaemon.com...
>>> What about putting a try-catch block in main ?
>>>
>>>
>>> In article <cl3o0e$j6i$1@digitaldaemon.com>, Asaf Karagila says...
>>>>
>>>> is there a way to install a global exception handler,
>>>> that will handle any unexpected error that occurs, that has no specific
>>>> handler in the code..
>>>> like, a default exception handler..
>>>>
>>>> - Asaf
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Fri, 29 Oct 2004 12:25:54 +0200, Asaf Karagila <kas1@netvision.net.il> wrote:

> yeah, i understood that earlier from your posts,
> but what if its an unexpected exception ?
> the only way i can think of now is to install the handler using
> the winapi SetUnhandledExceptionFilter, but i sorta hoped there would be
> something like that built-in the language..
>
> - Asaf.

catch{} or catch(Object o){}  will catch ALL exceptions. Even the Win32 exceptions are converted internally by D. Try something like this:

try
{
   // stuff
   *(cast(int*)0) = 0; // test
}
catch(ExpectedException e)
{
   // something
}
catch(SomeOtherExpectedException e)
{
   // something else
}
catch(Object e)
{
   writef("Unexpected exception: %s\n", e.toString());
}

In article <clt5q6$27f2$1@digitaldaemon.com>, Asaf Karagila says...
>
>yeah, i understood that earlier from your posts,
>but what if its an unexpected exception ?
>the only way i can think of now is to install the handler using
>the winapi SetUnhandledExceptionFilter, but i sorta hoped there would be
>something like that built-in the language..
>
>- Asaf.

What do you expect to be able to do with an "unexpected exception"?  Cancel with message or ignore and continue are the only things you could count on doing, and the ignore is probably difficult from a single catch point and the wrong thing to do.

If this is for testing, there are better ways.  If for production, why would you want to do anything but kill the process and fix the problem?  Log it and continue in some totally "unexpected, and wrong" state doing things wrong endlessly?  If there are known possibilities you are taking into account and have a plan to handle them, that's one thing and should be handled near the point it occurs, but global "unexpected" is either what it says or programmer laziness and/or error hiding.

The catch Object will trap everything after main() starts, and if it dies before that you don't have anything you're able to do except fix and restart anyway. Possibly you could have something in static initializations that would depend on system state at startup, but I can't think of an example.  If you have a specific example of why you need this we all would be interested I'm sure.

Are you trying to do all your trapping of errors at global (main()) level, and just spit out a message about what kind it was, maybe continue to find more? That sounds like debugging, and you would have to go in and trap closer to the error anyway if you have no other way to isolate it.  D compiler doesn't give you a whole pile of perhaps interrelated error messages - that's old batch compile mode - D presumes a fairly interactive mode of programming.  Big lists of errors usually don't lead to the next compile being clean and correct anyway. You should probably treat your testing similarly.  Test, find, fix, test, find, fix, ...

well,
i think i'll let out my "little secret",
i'm a reverser. when i learn a new language,
i usually try to write a crackme, or a reverseme,
its a bit more complicated than the simple hello world programs,
and it can contain many features i need to know for the future.

i wrote a crackme that reads a keyfile and test it with md5 and base64, what i forgot is to handle the case of the file containing plain data, which is illegal base64 characters. i catched it pretty well eventually. but i thought about using a global exception handler to catch ANY error, and apply it to the fact of something wrong with the registration process. or to use it as an anti-debugging technique just as well..

i think i know how to do it now. but i'm still not certain about it.
i tried couple of exceptions,
int 3;
int 1;
writing into the code section;
reading from [0000000] (it didn't go with mov EAX, dword [00000000]; a bug ?
i used xor ESI, ESI; lodsd;)

except the int3 which gave me the output Win32 Exception,
all the rest gave me Access Violation..
what i need to know is how to get the data about the exception.. where it
occured ?
then its possible to have it analyzing on run, and fixed by some self
modifying code..

- Asaf.

"larrycowan" <larrycowan_member@pathlink.com> wrote in message news:cluu3j$p11$1@digitaldaemon.com...
> In article <clt5q6$27f2$1@digitaldaemon.com>, Asaf Karagila says...
>>
>>yeah, i understood that earlier from your posts,
>>but what if its an unexpected exception ?
>>the only way i can think of now is to install the handler using
>>the winapi SetUnhandledExceptionFilter, but i sorta hoped there would be
>>something like that built-in the language..
>>
>>- Asaf.
>
> What do you expect to be able to do with an "unexpected exception"?
> Cancel with
> message or ignore and continue are the only things you could count on
> doing, and
> the ignore is probably difficult from a single catch point and the wrong
> thing
> to do.
>
> If this is for testing, there are better ways.  If for production, why
> would you
> want to do anything but kill the process and fix the problem?  Log it and
> continue in some totally "unexpected, and wrong" state doing things wrong
> endlessly?  If there are known possibilities you are taking into account
> and
> have a plan to handle them, that's one thing and should be handled near
> the
> point it occurs, but global "unexpected" is either what it says or
> programmer
> laziness and/or error hiding.
>
> The catch Object will trap everything after main() starts, and if it dies
> before
> that you don't have anything you're able to do except fix and restart
> anyway.
> Possibly you could have something in static initializations that would
> depend on
> system state at startup, but I can't think of an example.  If you have a
> specific example of why you need this we all would be interested I'm sure.
>
> Are you trying to do all your trapping of errors at global (main()) level,
> and
> just spit out a message about what kind it was, maybe continue to find
> more?
> That sounds like debugging, and you would have to go in and trap closer to
> the
> error anyway if you have no other way to isolate it.  D compiler doesn't
> give
> you a whole pile of perhaps interrelated error messages - that's old batch
> compile mode - D presumes a fairly interactive mode of programming.  Big
> lists
> of errors usually don't lead to the next compile being clean and correct
> anyway.
> You should probably treat your testing similarly.  Test, find, fix, test,
> find,
> fix, ...
>
>
>